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10 La presente invention a pour objet un procdde de controle d'integrite 
d' execution de programmes par verification d'empreintes de traces 
d' execution. 

Elle s'applique notamment au controle d'integrite d'execution de programmes, 
15 ladite execution de programmes mettant a jour une empreinte representative 

.4 

du chemin d'execution et/ou des donnees manipulees, sachant qu'en desi 
points determines du programme, la valeur courante de T empreinte est ;,, 
comparee a une valeur attendue^ > 

20 Certains petits systemes embarques, comme par exemple les cartes a puce, 
sont con9US pour proteger les donnees et programmes qu'ils contiennent. En 
particulier, le support materiel de ces systemes rend tres difficile Tobservation 
et la modification des donnees stockees, y compris lors de T execution des 
programmes. 

25 

La protection n'est toutefois pas totale, Ces systemes peuvent etre exposes a 
des actions malveillantes (aussi appelees « attaques ») qui visent a alterer le 
bon fonctionnement du systeme et des programmes, ou a devoiler des 
infonnations confidentielles. Des attaques physiques (aussi dites materielles) 
30 sont par exemple des perturbations de T alimentation electrique, des 
bombardements par des rayomiements, la destruction de portes logiques^ etc. 
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La presente invention a pour objet un precede de controle d'integrite 
d' execution de programmes par verification d'empreintes de traces 
d' execution. 

Elle s'applique notamment au controle d'integrite d'execution de programmes, 
ladite execution de programmes mettant a jour une empreinte representative 
du chemin d'execution et/ou des donn^es manipuI6es, sachant qu'en des 
points d^ermines du programme, la valeur courante de 1' empreinte est 
comparee a une valeur attendue. 

Certains petits syst^mes embarques, comme par exemple les cartes a puce, 
sont con9us pour proteger les donnees et programmes qu'ils contiennent. En 
particulier, le support materiel de ces systemes rend tres difficile I'observation 
et la modification des donnees stockees, y corapris lors de 1' execution des 
programmes. 

La protection n'est toutefois pas totale. Ces systemes peuvent etre exposes k 
des actions malveiliantes (aussi appelees « attaques ») qui visent a alterer le 
bon fonctionnement du systdme et des programmes, ou k devoiler des 
infoi-mations confidentielles. Des attaques physiques (aussi dites materielles) 
sont par exemple des perturbations de I'alimentation €lectrique, des 
bombardements par des rayonnements, la destruction de portes logiques, etc. 
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De telles attaques peuvent conduire a des dysfonctiormements dii programme 
execute sur la carte : les instructions et les donnees lues depuis la memoire 
peuvent etre incorrecteSj et le processeur peut executer incorrectement 
certaines instructions. De telles perturbations peuvent rendre invalide du code 
5 qui verifie des conditions de securite avant d'operer certaines actions 
sensibles. 

Soit Texemple (simplifie) du code suivant, ecrit en langage C : 
if (! condition 1()) goto error; 
10 if (! condition2()) goto error; 

do_s ensiti ve_action() ; 



action sensible « do_sensitive_action() » n'est normal ement executee que si 
les deux conditions « condition 1() » et « condition2() » sont satisfaites. 
15 Neanmoins, des perturbations physiques peuvent amener le processeur a sauter I 

■4 

directeraent par-dessus le code des deux « if » ou a lire depuis la memoire une 
serie d' instructions differentes du code des deux «if». Dans ce cas, le 
processeur peut executer « do_sensitive_action() » meme si les tests 
« condition 1() » et « condition2() » ne sont pas satisfaits. 

20 

Une technique connue pour « durcir » un programme contre ce genre 
d'attaques consiste a introduire de la redondance entre le flot de controle du 
programme et les valeurs de certaines variables auxiliaires. En d'autres 
termes, on utilise des variables auxiliaires pour garder trace du fait que 
25 r execution est bien passee par toutes les verifications de conditions de 
securite. Dans le cas de Texemple ci-dessus, on pourrait ecrire : 
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De telles attaques peuvent conduire a des dysfonctionnements du programme 
execute sur la carte : les instructions et les donnees lues depuis la memoire 
peuvent Stre incorrectes, et le processeur pent executer incorrectement 
certaines instructions, De telles perturbations peuvent rendre invalide du code 
5 qui verifie des conditions de securite avant d'operer certaines actions 
sensibles. 

Soit Texemple (simplifie) du code suivant, ^crit en langage C : 
if (! conditionlQ) goto error; 
10 if (! condition2()) goto error; 

do__sensiti ve_action() ; 



L' action sensible « do sensitive actionQ » n'^est nonnalement executee que si 
les deux conditions « conditionlQ » et « condition2() » sont satisfaites. 
15 Neanmoins, des perturbations physiques peuvent amener le processeur a sauter 
directement par-dessus le code des deux « if » ou a lire depuis la memoire une 
serie d' instructions differentes du code des deux « if ». Dans ce cas, le 
processeur peut executer « do_sensitive_action() » meme si les tests 
« conditionlQ » et « condition2Q » ne sont pas satisfaits. 

20 

Une technique connue pour « durcir » un programme centre ce genre 
d' attaques consiste a introduire de la redondance entre le flot de controle du 
programme et les valeurs de certaines variables auxiliaires. En d'autres 
termes, on utilise des variables auxiliaires pour garder trace du fait que 
25 r execution est bien passee par toutes les verifications de conditions de 
securite. Dans le cas de Texemple ci-dessus, on pourrait ecrire : 
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trace = 0; 

if (condition 10) trace j= 1; else goto error; 
if (condition2()) trace |= 2; else goto eiTor; 
if (trace == 3) do_sensitive_action(); 

Ainsi, si les deux premiers « if » ne sont pas executes correctement, il y a de 
bonnes chances que la variable « trace » ne soit pas egale ^ 3 ^ la fin, et que 
Taction « do_sensitive_actionO » ne soit done pas execut6e. 

Mdme dans ce cas, une perturbation poiuxait faire en sorte que le test « trace 
== 3 » soit toujours vrai ou soit lui aussi ignore. De maniere g6nerale, pour la 
pertinence de F invention presentee ici, on fait I'hypothese que les 
perturbations causees par des attaques physiques sont relativement grossieres : 
elles peuvent inactiver Texecution d'une pailie du programme ou changer le ? 
contenu apparent d'une partie de la memoire, mais i'etendue de cette partie i 
n'est pas contrSlable finement par Pattaquant. t 

Cette approche peut se generaliser de la maniere suivante, Le programme tient 
a jour une valeur representative des points de controle importants par lesqueis 
passe son execution. Cette valeur peut etre une empreinte (un « hash »), par 
exemple une somme de contrdle (« checksum »), calculee sur des entiers qui 
caracterisent ces points de controle importants. Avant d'executer une 
operation sensible, cette valeui- mise a jour en cours d' execution peut etre 
comparee a sa valeur normale (attendue), pr^calculee manuellement par le 
programmeur a partir de la structui-e de contr61e du programme. Pai- exemple : 
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trace = 0; 



if (condition 1()) trace |= 1; else goto error; 
if (condition2()) trace |= 2; else goto error; 
if (trace == 3) do_sensitive_action(); 



Ainsi, si les deux premiers « if » ne sont pas executes correctement, il y a de 
bonnes chances que la variable « trace » ne soit pas egale a 3 a la fin, et que 
Taction « do_sensitive_action() » ne soit done pas ex6cut6e. 



10 M6me dans ce cas, une perturbation pourrait faire en sorte que le test « trace 
3 » soit toujours vrai ou soit lui aussi ignore. De maniere generale, pour la 
pertinence de T invention presentee ici^ on fait Thypothese que les 
perturbations caus6es par des attaques physiques sont relativement grossieres : 
elles peuvent inactiver T execution d'une partie du programme ou changer le 

15 contenu apparent d'une partie de la memoire, mais Tetendue de cette partie 
n'est pas controlable finement par Fattaquant, 



Cette approche pent se generaliser de la maniere suivante, Le programme tient 
a jour une valeur representative des points de controle importants par lesquels 

20 passe son execution. Cette valeur pent etre une empreinte (un « hash »), par 
exemple une somme de controle (« checksum »), calculee sur des entiers qui 
caracterisent ces points de controle importants. Avant d'executer une 
operation sensible, cette valeur mise a jour en cours d' execution pent etre 
comparee a sa valeur normale (attendue), precalculee manuellement par le 

25 programmeur a partir de la stmcture de controle du programme. Par exemple : 
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trace = 42; 

for (i = 0; i < 4; i++) { 

if (provided.jpm[i] != actualjpiii[i]) goto error; 
trace = h(traoe, i); 

5 > 

if (trace = 2346) do_sensitive_action(); 

U faut cependant noter que ce n'est pas ainsi qu'une verification de code PIN 
est habituellement codee ; 11 s'agit juste ici d'un exemple illustratif de Pusage 
10 du calcul d'empreinte. 

L'operateur de hacliage utilise ici est la congruence lineaire « li(t,x) = ((33 t) 
mod (2"^ 16)) xor x » ou : 

« « a '-^ b » represente le produit de « a » par « b », 

15 ® « a mod b » represente le reste de la division de « a » par « b » (c'est-a-dire 
le modulo)^ 

® « a ^ b » represente T elevation de « a » a la puissance « b », 

® « a xor b » est T operation « ou logique exclusif » sur les bits representant 
« a » et « b ». 

20 

La valeur 2346 n'est autre que « h(h(h(h(425 0), 1), 2),, 3) », c'est-a-dire 
Fempreinte de T execution normale de la boucle (4 tours pour « i » variant de 0 
a 3), Si la boucle n'^est pas executee ou si elle se tennine anormalement avant 
d' avoir fait 4 tours, la valeur de la variable «tt^ace» avant Fappel de 
25 « do_sensitive_action() » sera tr^s probablement differente de 2346. 
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trace = 42; 

for (i - 0; i < 4; i++) { 

if (provided._pin[i] != actual__pin[i]) goto error; 
trace = h(trace, i); 

} 

if (trace == 2346) do_sensitive_action(); 



II faut cependant noter que ce n'est pas ainsi qu'une verification de code PIN 
est habituellement cod^e ; il s'agit juste ici d'un exemple illustratif de I'usage 
du calcul d'empreinte. 

L'operateur de hachage utilise ici est la congruence lineaire « h(t,x) = ((33 * t) 
mod (2^16)) xor x » oij : 

® « a * b » represente le produit de « a » par « b », 

• « a mod b » represente le reste de la division de « a » par « b » (c'est-a-dire 
le modulo), 

» « a ^ b » represente T elevation de « a » a la puissance « b », 

• « a xor b » est I'op^ration « ou logique exclusif » sur ies bits representant 
« a » et « b ». 

La valeur 2346 n'est autre que « h(h(h(h(42, 0), 1), 2), 3) », c'est-a-dire 
I'empreinte de I'execution normale de la boucle (4 tours pour « i » variant de 0 
a 3). Si la boucle n'est pas execut6e ou si elle se termine anormalement avant 
d' avoir fait 4 tours, la valeur de la vaiiable « trace » avant I'appel de 
« do_sensitive_actionO » sera tres probablement differente de 2346. 
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On peut voir cet operateur de hacliage « h » comme un operateur qui permet 
de calculer incrementalement une fonction de hachage « H » qui opere sur des 
sequences d'entiers qui caracterisent lesdits points de controle importants. 
Cette fonction de iiachage sur les sequences d' observations est definie par : 
« H(To, ii, ia, - • i„) = h(. . .h(h(To, ii), ii)..., in) »• 



Pour pouvoir 6tre utilisee dans des petits systdmes embarques disposants de 
faibles capacit6s de calcul, 1' operateur de hachage «h» doit etre rapide a 
calculer. De plus, la fonction de hachage « H » resultante doit aussi Btre 
resistante aux pre-images : la probabilite pour que I'empreinte 
«H(To, ii, in) » d'une sequence aMatoire « Tq, ii, i„ » soit egale a une 
valeur donnee doit etre faible (de i'ordre de 2"^ ou B est le nombre de bits 
pour coder la valeur de Fempreinte.) 

Dans certains cas decrits ci-dessous, il pourra aussi 6tre utile de disposer d'un 
operateur de hachage « h » qui soit inversible en son premier argument : pour 
toutes valeurs « t' » et « x », il existe « t » tel que « t' = h(t, x) ». 

On peut par exemple utiliser pour « h » une congmence lineaire, comme c'est 
le cas dans 1' exemple donne ci-dessus. Cette congruence lineaire a de plus la 
propriete d'inversibilite. Plus g^n6ralement, on peut utiliser n'importe quelle 
fonction qui combine les operations suivantes : addition, soustraction, ou 
logique exclusif (xor) avec une constante ou avec « x » ; rotation d'un nombre 
constant de bits ; multiplication par une constante impaire. 

On peut utiliser egalement une fonction de conttole de redondance cyclique 
(CRC), conmie par exemple CRC-16 ; une telle fonction peut 6tre calculee de 
maniere efficace a I'aide de tables precalcul6es. 



regue le 08/01/04 

On peut voir cet operateur de hachage « h » comme un operateur qui permet 
de calculer incremental ement une fonction de hachage « H » qui opere sur des 
sequences d'entiers qui caracterisent lesdits points de controle importants. 
Cette fonction de hachage sur les sequences d'observations est definie par : 
5 « H(To, ii, ia, . ► in) ^ h(. . •h(h(To, ii), 12)- in) »• 

Pour pouvoir etre utilisee dans des petits systemes embarques disposants de 
faibles capacites de calcul^^ T operateur de hachage « h » doit etre rapide a 
calculer, De plus, la fonction de hachage «H» resultante doit aussi etre 
10 resistante aux pre-images : la probabiiite pour que Pempreinte 
« H(To. ii, .... in) » d'une sequence aleatoire « To, iu in » soit egale a une 
valeur donnee doit etre faible (de Tordre de 2"^ ou B est le nombre de bits 
pour coder la valeur de Fempreinte,) 

15 Dans certains cas decrits ci-dessous, il pourra aussi etre utile de disposer d'un 
operateur de hachage « h » qui soit inversible en son premier argument : pour 
toutes valeurs « V » et « x », il existe « t » tel que « t' == h(t, x) ». 

On peut par exemple utiliser pour « h » une congruence lineaire, comme c'est 
20 le cas dans T exemple donne ci-dessus. Cette congruence lineaire a de plus la 
propriete d'inversibilite. Plus generalement, on peut utiliser n'importe quelle 
fonction qui combine les operations suivantes : addition, soustraction, ou 
logique exclusif (xor) avec une constante ou avec « x » ; rotation d'un nombre 
constant de bits ; multiplication par une constante impaire. 

25 

On peut utiliser egalement une fonction de contrSle de redondance cyclique 
(CRC), comme par exemple CRC-ie ; une telle fonction peut etre calculee de 
maniere efficace a Taide de tables precalculees. 



> 
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En revanche^ meme si une somme de controle (checksum, defiiiie comme la 
somme des entiers passes en ai^gument) a bien les bonnes proprietes de rapidite 
de calculj de resistance aux pre-images, et d^inversibilite, elle est peu 
satisfaisante car la fonction de hacliage obtenue est insensible a Tordre des 
5 arguments. 

A Tautre extremite du spectre se ti*ouvent des fonctions de hachage 
cryptographiques (digests, comme etc.) qui sont tres sures mais 

aussi couteuses a calculer. 

10 

La prise d'empreinte peut se decrire a Taide de deux operations principaies 
d' affectation et de mise a jour d'empreinte : « setTrace(T) » fixe la valeur 
initiale de Tempreinte a «T» (typiquement, une valeur quelconque), et 
« addTrace(N) » ajoute a la trace un entier « N » caracteristique d'une ' 
15 observation ' de P execution du programme, Dans Texemple ci-dessus, 

« setTrace(T) » correspond a Taffectation « trace = T; » et « addTrace(N) » 4 
correspond a la mise a jour de Tempreinte par « trace = h(trace, N) ». 

La valeur « N » foumie loi*s d'une operation « addTrace(N) » peut elle-meme 
20 etre le resultat d'une fonction de hachage. Plus rentier « N » est representatif 
de Texecution locale du programme, c'est-a-dire plus « N » varie en presence 
d'une perturbation possible de Texecution, meilleur est le pouvoir de detection 
d'une attaque. 

25 La verification d'empreinte peut se decrire a Taide d'une unique operation : 
« checkTrace(T) » verifie que la valeur courante de Tempreinte est bien « T ». 
Dans le cas contraire, c'est une indication que le programme a subi une 
attaque. En toute rigueur, des systemes comme des cartes a puce s'usent et une 

difference d'empreinte pourrait aussi etre le signe d'une defaillance materielle. 



regue le 08/01/04 

-6- 



En revanche^, meme si une somme de controle (checksum, definie comme la 
somme des entiers passes en argument) a bien les bonnes proprietes de rapidite 
de calcul-^ de resistance aux pre-images, et d'inversibilit^j elle est peu 
satisfaisante car la fonction de hachage obtenue est insensible a Fordre des 
5 arguments* 



A i' autre extremite du spectre se trouvent des fonctions de hachage 
cryptographiques (digests, comme SHA-1, MD-5, etc) qui sont tres sures mais 
aussi couteuses a calculer, 

10 

La prise d'empreinte peut se decrire a Taide de deux operations principales 
d'affectation et de mise a jour d'empreinte : « setTrace(T) » fixe la valeur 
initiale de Tempreinte a «T» (typiquement, une valeur quelconque), et 
« addTrace(N) » ajoute a la trace un entier «N» caracteristique d'une 
15 observation de T execution du programme. Dans Pexemple ci-dessus, 
« setTrace(T) » coiTespond a T affectation « trace = T; » et « addTrace(N) » 
correspond a la mise a jour de Tempreinte par « trace = h(trace^ N) ». 



La valeur « N » fouraie lors d'une operation « addTrace(N) » peut elle-m6me 
20 etre le resultat d'une fonction de hachage. Plus Pentier « N » est representatif 
de Texecution locale du programme, c'est-a-dire plus « N » varie en presence 
d'une perturbation possible de Texecution, meilleur est le pouvoir de detection 
d'une attaque, 

25 La verification d'empreinte peut se decrire a Taide d'une unique operation : 
« checkTrace(T) » verifie que la valeur courante de Tempreinte est bien « T ». 
Dans le cas contraire, c'est une indication que le programme a subi une 
attaque. En toute rigueur, des systemes comme des cartes a puce s'usent et une 
difference d'empreinte pourrait aussi etre le signe d'une defaillance materielle. 
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Dans tous les cas, le programme ne peut plus rendre le service pour lequel il 
est con9U. Dans des systemes critiques, les mesures prises en cette 
circonstance consistent typiquement a securiser certaines domiees du 
5 programme et a inten'ompre, dejSnitivement ou non, son execution. Lorsque 
c'est materiellement possible, un signal sonore ou visuel peut en outre avertir 
Tutilisateur du dj^sfonctionnement. 

Au vu de Texemple ci-dessus^ il est manifeste que la mise en c^uvre de cette 
10 technique demande beaucoup d'efforts de la part du programmeur^ d'une part 
pour inserer les etapes de calcul de Tempreinte, de P autre pour calculer les 
valeurs attendues de Tempreinte aux points ou elle devra etre yerifiee. 

Compte tenu des problemes precedemment evoques, Tinvention a plus 
15 particulierement pour but la generalisation de cette technique et son 
automatisation . 

A cet effetj elle propose un precede de controle d'integrite d'execution de 

programmes par verification d'empreintes de traces d' execution mettant en 
20 ceuvre : 

- la mise a jour d'une empreinte representative du chemin d'execution 
et/ou des donnees manipulees lors de T execution du programme, 

- la comparaison de la valeur courante de T empreinte (calculee 
dynamiquement) a une valeur attendue (fixee statiquement> egale la 

25 valeur que doit avoir Tempreinte si Texecution du programme n*est 

pas perturbee) en des points determines du programme^ 

- la realisation d'un traitement particulier effectue par le programme 
au cas ou T empreinte courante differ e de la valeur attendue. 



I 
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Dans tous les cas, le programme ne peut plus rendre le service pour lequel il 
est con9u. Dans des systoes critiques, les mesures prises en cette 
circonstance consistent typiquement a securiser certaines donnees du 
programme et a interrompre, definitivement ou non, son execution. Lorsque 
c'est raateriellement possible, un signal sonore ou visuel peut en outre avertir 
I'utilisateur du dysfonctionnement. 

Au vu de I'exemple ci-dessus, il est manifeste que la mise en oeuvre de cette 
technique demande beaucoup d'efforts de la pait du programmeur, d'une part 
pour inserer les etapes de calcul de I'empreinte, de Tautre pour calculer les 
valeurs attendues de I'empreinte aux points ou elle devra etre verifiee. 

Compte tenu des problemes precedemment evoques, T invention a plus 
particulierement pour but la generalisation de cette technique et son 
automatisation. 

A cet effet, elle propose un precede de controle d'integrite d'ex6cution de 
programmes par verification d'empreintes de traces d' execution mettant en 
oeuvre : 

- la mise a jour d'une empreinte representative du chemin d' execution 
et/ou des donnees manipulees lors de I'ex^cution du programme, 

- la comparaison de la valeur courante de I'empreinte (calculee 
dynamiquement) a une valeur attendue (fixee statiquement, egale la 
valeur que doit avoir I'empreinte si I'execution du programme n'est 
pas perturbee) en des points determines du programme, 

- la realisation d'un traitement particulier effectue par le programme 
au cas ot I'empreinte courante diffdre de la valeur attendue. 
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Dans tous les cas, le programme ne peut plus rendre le service poiir lequel il 
est con9u. Dans des systemes critiques, les mesures prises en cette 
circonstance consistent typiquement a secxuiser certaines donnees du 
5 programme et a iaterrompre, defibaitivement ou non, son execution- Lorsque 
c'est materiellement possible, xm signal sonore ou visuel peut en outre avertir 
Tutilisateur du dysfonctionnement. 

Au vu de Texempie ci-dessus, il est manifeste que la niise en asuvre de cette 
10 technique demande beaucoup d' efforts de la part du prograrmneur, d'une part 
pour inserer les etapes de calcul de Tempreinte, de I'autre pour calculer les 
valeurs attendues de Fempreinte aux points ou elle devra atre verifiee. 

i 

Compte tenu des problemes precedemment evoques, rinveation a plus 
15 particulierement pour but la g6neralisation de cette technique et son 
automatisation. 

A cet effetj elle propose un precede de contrdle d'integrite d'execution de 
programmes par verification d'empreintes de traces d'execution mettaat en 
20 oeuvre ; 

- la mise a jour d'une empreinte representative du chemin d'execution 
et/ou des donnees manipulees lors de T execution du programme, 

- la comparaison de ladite empreinte (valeur courante, calculee 
dynamiquement) a une valeur attendue (fixee statiquement, egale la 

25 valeur que doit avoir Tempreinte si Texecution du programme n'est 

pas perturbee) en des points determines du programme, 

- la realisation d'un traitement particulier dans le cas ou Fempreinte 
courante differe de la valeur attendue. 
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Ce precede pourra prendre en compte : 



. que ladite empreinte ne porte que sur des fragments de code 
critiques du programme. 



5 



- que les valeurs attendues de 1' empreinte en des points donnes du 
programme sont determinees par une analyse statique de programme 
qui modifie eventueilement le code de programme pour rendre les 
valeurs d' empreinte previsibles. 



10 Ce procede et ses perfect! onnements sont decrits plus en detail ci-apres a titre 
d'exemples non limitatifs. 

L' analyse de programme pour la determination des valeurs d'empreinte 
attendues peut se decomposer en plusieurs etapes. On considere tout d'abord 
15 le cas d'une routine (methode, sous-programme, etc.) du programme. 

Dans le cas ou toutes les instructions separant le debut de la routine d'un point 
de controle d' empreinte sont lineaires, c'est-a-dire ne contiemient pas de 
branchements, la valeur attendue de T empreinte est simplement 
20 « h(. . .h(h(To> ii), i2). ^ in) » ou « To » est la valeur initiale de P empreinte et ou 
« ii, i„» sont les entiers representatifs de Texecution au divers points 
d' observation sur le chemin d' execution. 

Plus generalement, etant donne une decomposition d'une routine sous fomie 
d'un graphe de blocs de base (basic blocks), si Ton connait statiquement la 
25 valeur de Tempreinte au debut d'un bloc de base, on connait de la mSme 
maniere sa valeur en tout point du bloc. 
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Ce precede pourra prendre en compte : 

- que ladite empreinte ne porte que sur des fragments de code 
critiques du programme, 

- que les valeurs attendues de Tempreinte en des points donnes du 
programme sent determinees par une analyse statique de programme 
qui modifie eventuellement le code de programme pour rendre les 
valeurs d' empreinte previsibles. 

Ce procede et ses perfectionnements sont d6crits plus en detail ci-apres a titre 
d'exemples non limitatifs. 



L'analyse de programme pour la determination des valeurs d'empreinte 
attendues peut se decomposer en plusieurs etapes. On considere tout d'abord 
le cas d'une routine (methode, sous-programme, etc.) du programme. 



Dans le cas ou toutes les instructions s6parant le debut de la routine d'un point 
de controle d'empreinte sont lineaires, c'est-a-dire ne contiennent pas de 
branchements, la valeur attendue de I'empreinte est simplement 
« h(. . .h(h(To, ii), k)' . in) » ou « Tq » est la valeur initiale de I'empreinte et ou 
«ii, ...,i„» sont les entiers representatifs de I' execution au divers points 
d' observation sur le chemin d' execution. 

Plus generalement, etant donne une decomposition d'une routine sous forme 
d'un graphe de blocs de base (basic blocks), si I'on connatt statiquement la 
valeur de I'empreinte au d^but d'un bloc de base, on connatt de la meme 
maniere sa valeur en tout point du bloc. 
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Lorsque plusieurs chemins d' execution differents menent en un meme point de 
programme, 11 n'est pas possible de predire « la » valeur d'empreinte attendue 
en ce point de programme puisqu'il y en a en fait plusieurs. Dans ce cas^ on 
«egalise» les valeurs de Tempreinte aux points de jointure dans le flot de 
5 controle : sur chaque branche qui mdne au point de jointure (sauf 
eventuelleraent une des branches), on ajoute a Tempreinte courante une valeur 
constante telle que Tempreinte resultante est la mSme pour chaque branche^ 
une fois atteint le point de jointure. Cette addition pent se faire explicitement 
dans le code, par exemple par operation directe sur la valeur de I'empreinte ou 
10 par appel a une routine dediee. Soit par exemple le prograrmne suivant : 

if (cond) { 

addTrace(l); 

* • « 

addTrace(2); 
15 } else { 

addTrace(3); 

« « * 

addTrace(4); 

} 

20 Si I'empreinte a la valeur « Tq » avant le « if », elle aura respectivement les 
valeurs «h(h(To, 1), 2) » et « h(h(To, 3), 4) » a la fin de chacune des deux 
branches de ce « if ». Pour etablir un point de controle d'empreinte apres ce 
« if », on pent egaliser les branches de la maniere suivante : 
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Lorsque piusieurs chemins d'execution differents menent en un meme point de 
programme, il n'est pas possible de pr^dire « la » valeur d'empreinte attendue 
en ce point de programme puisqu'il y en a en fait piusieurs. Dans ce cas, on 
« egalise » les valeurs de I'empreinte aux points de jointure dans le flot de 
contrdle : sur chaque branche qui mene au point de jointure (sauf 
eventuellement une des branches), on ajoute a I'empreinte courante une valeur 
constante telle que I'empreinte r6sultante est la mSme pour chaque branche, 
une fois atteint le point de jointure. Cette addition peut se faire explicitement 
dans le code, par exeniple par operation directe sur la valeur de Fempreinte ou 
pai- appel a une routine dediee. Soit par exemple le programme suivant : 

if (cond) { 

addTrace(l); 

« • « 

addTrace(2); 
} else { 

addTrace(3); 
» • • 

addTrace(4); 

} 

Si I'empreinte a la valeur « To » avant le « if », elle aura respectivement les 
valeurs « h(h(To, 1), 2) » et « h(h(To, 3), 4) » a la fm de chacune des deux 
branches de ce « if ». Pour etablir un point de contrdle d'empreinte apres ce 
« if », on peut egaliser les branches de la maniere suivante : 
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if (cond) { 



addTrace(l); 



addTrace(2); 



5 



} else { 



addTrace(3); 



addTrace(4); 



adj us tTr ace(X) ; 



} 



checkTrace(Y); 
avec les definitions suivantes : 

® « adjustTrace(N) » ajoute rentier « N » a la valeur courante de 
rempreinte, 

15 ® « X » est egal a « h(h(To5 1), 2) - h(li(To, 3), 4) », 
• « Y » est egal a « h(h(Toi> 1), 2) ». 

Ainsi, quel que soit le chemin d'execution pris, Tempreinte vaudra toujours 
« Y » apres le « if Le fait d'additionner la valeur « X » a la valeur courante 
20 de Tempreinte rend cette empreinte previsible tout en preservant le fait qu'elle 
est difficile a falsifier, L'ajustement aurait pu etre pratique de maniere 
symetrique sur la premiere branche du « if » plutot que sur la seconde, 

Ce schema s' applique aussi au cas des boucles dent le nombre d' iterations est 
25 . indetermine : a chaque tour de boucle, Tempreinte est ajustee pour revenir a la 
menie valeur initials 
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20 



if (cond) { 



addTrace(l); 



addTrace(2); 



} else { 



25 



addTrace(3); 



addTrace(4); 
adjustTrace(X); 



10 ) 



checkTrace(Y); 
avec les definitions suivantes : 

• « adjustTrace(N) » ajoute I'entier «N» a la valeur courante de 
I'empreinte, 

15 • « X » est egal a « h(h(To, 1 ), 2) - h(h(To, 3), 4) », 
® « Y » est egal a « h(h(To, 1), 2) ». 



Ainsi, quel que soit le chemin d'execution pris, I'empreinte vaudra toujours 
« Y » apres le « if ». Le fait d'additionner la valeur « X » a la valeur courante 
de I'empreinte rend cette empreinte previsible tout en preservant le fait qu'elle 
est difficile a falsifier. L'ajustement aurait pu 6tre pratique de maniere 
symetrique sur la premiere branche du « if » plutot que sur la seconde. 



Ce schema s'applique aussi au cas des boucles dont le nombre d'iterations est 
indetermin^ : a chaque tour de boucle, I'empreinte est ajustee pour revenir a la 
meme valeur initiale. 
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L'operation d'ajustement d'empreinte « adjustTrace» s'ajoute aux operations 
de mise a jour d'empreinte («addTrace») et d'affectation d'empreinte 
(« setTrace ») pour former 1' ensemble des operations de « prise d'empreinte ». 

5 

L'operation d'ajustement d'empreinte « adjustTrace(N) » n'a pas a etre 
necessairement une operation basee sur une operation d' addition du genre 
« trace = trace + N; ». EUe peut etre plus generalement defmie comme 
« trace = adjust(trace, N); » oil « adjust(T, N) » est une fonction inversible en 
10 son premier argument: pour toute empreinte d'origine «T» et toute 
empreinte cible « T' », il suffit de savoir determiner « N = delta(T» T') » tel 
que « adjust(T, N) = T' ». 

On retrouve ainsi le cas de 1 ' addition : « adjust(T, N) = T + N » et 
15 « delta(T, T') = T' - T ». Mais on peut aussi par exemple utiliser le « ou 
logique exclusif » : « adjust(T, N) = T xor N » et « delta(T, T') = T xor T' ». 

L'ajustement d'empreinte « adjustTrace(delta(T, T')); » envoie I'empreinte 
« T » sur r empreinte « T' » en preservant la difficulte de falsification. 

20 Les gestionnaires d'exceptions (exception handlers) d'un programme rendent 
difficile la determination statique des valeurs de I'empreinte. En effet, 
r execution peut se brancher au debut du code du gestionnaire a partir de 
n'importe quelle instruction couverte par ce gestionnaire. La valeur de 
I'empreinte au debut du code du gestionnaire n'est done pas previsible 

25 statiquement La mise en place d' ajusteraents d'empreinte comme decrits ci- 
dessus pour toutes les instructions couvertes par un gestionnaire d' exception 
permet en principe d' assurer une valeur d'empreinte comiue au debut du 

4 

gestionnaire. Cependant, comme le nombre d'ajustements necessaires est 
grand, cela peut Stre couteux en taille de code, en particulier si les ajustements 
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L'operation d'ajustement d'empreinte « adjustTrace » s'ajoute aux operations 
de mise a jour d'empreinte (« addTrace ») et d'affectation d'empreinte 
(« setTrace ») pour former F ensemble des operations de « prise d'empreinte ». 

5 

L' operation d'ajustement d'empreinte « adjustTrace(N) » n'a pas a etre 
n^cessairement une operation basee sur une operation d' addition du genre 
« trace ~ trace + N; ». Eile peut etre plus generalement definie comme 
« trace = adjust(trace, N); » ou « adjust(T5 N) » est une fonction inversible en 
10 son premier argument: pour toute empreinte d'origine «T» et toute 
empreinte cible « T' il suffit de savoir determiner « N = delta(T5 T^) » tel 
que « adjust(T, N) = T' ». 



On retrouve ainsi le cas de T addition : « adjust(T5 N) = T + N » et 
15 « delta(T, T") = T' — T »» Mais on peut aussi, pai* exemple utiliser le « ou 
logique exclusif » : « adjustCT, N) = T xor N » et « delta(T5 T') = T xor T' ». 

L'ajustement d' empreinte « adjustTrace(delta(T5 T')); » envoie T empreinte 
« T » sur r empreinte « T' » en preservant la difficulte de falsification. 



20 Les gestionnaires d' exceptions (exception handlers) d'un programme rendent 
difficile la determination statique des valeurs de I'empreinte. En effet, 
P execution peut se brancher au debut du code du gestionnaire a partir de 
n'importe quelle instruction couverte par ce gestionnaire. La valeur de 
Tempreinte au debut du code du gestionnaire n'est done pas previsible 

25 statiquement. La mise en place d'ajustements d' empreinte comme decrits ci- 
dessus pour toutes les instructions couvertes par un gestionnaire d'exception 
permet en principe d'assurer une valeur d'empreinte connue au debut du 
gestionnaire, Cependant, comme le nombre d'ajustements necessaires est 
grand, cela peut etre couteux en taille de code, en particulier si les ajustements 
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sont codes explicitement par des appels de routine du type 
« adjusteTrace(N) ». En outre, les ajustements auraient comme effet 
secondaire de rendre Tempreinte constante sur tout Pintervalle du code 
couvert par im gestionnaire d' exception. L'empreinte serait done alors 
inefficace pour detecter les perturbations d' execution. 

Une solution k ce probleme est de forcer Fempreinte a une valeur connue 
statiquement lorsque T execution entre dans un gestionuaaire d' exceptions. Cela 
pent etre fait par Tinterprete de la machine virtuelle, lorsqu'il traite le 
rattrapage d'une exception. Une autre possibilite est d'inserer un appel a une 
routine « setTrace(T) » au debut de chaque gestionnaire d' exceptions, ou « T » 
est une valeur choisie arbitrairement ; cette routine positionne la variable 
« trace » a la valeur de son argument. 

Avec cette solution, la propriete de controle d'integrite d'execution est 
localement perdue entre le fragment d' execution qui precede le branchement 
et celui qui le suit. Mais elle reste globalement preservee sur T ensemble de 
r execution du programme. 

Cette m6thode peut plus generalement s'appliquer a tons les points de forte 
convergence du flot de controle de la routine. 

Les subroutines, dans des langages comme ceux de la machine virtuelle 
«Java» (JVM) ou «Java Card » (JCVM) (marques deposees par Sun 
Mycrosystems), posent par exempie un probleme similaire, Elles peuvent en 
effet etre appelees depuis plusieurs points du code, avec des valeurs 
differentes pour I'empreinte. On peut les traiter de la meme maniere que les 
gestiomiaires d'exception, en for9ant la valeur de Tempreinte lorsqu'on entre 
dans une subroutine. Les points d'appels de subroutines etant bien delimites 
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sont codes explicitement par des appels de routine du type 

« adjusteTrace(N) ». En outre, les ajustements auraient comme effet 

secondaire de rendre Tempreinte constante sur tout Tintervalle du code 

convert par un gestionnaire d' exception, L'empreinte serait done aiors 
5 inefficace pour detecter les perturbations d'execution. 

Une solution a ce probleme est de forcer Tempreinte k une valeur connue 

statiquement lorsque Texecution entre dans un gestionnaire d'exceptions* Cela 
pent etre fait par I'interprete de la machine virtuelle, iorsqu'il traite le 
10 rattrapage d'une exception, Une autre possibilite est d'inserer un appel a une 
routine « setTrace(T) » au debut de cliaque gestionnaire d' exceptions, ou « T » 
est une valeur choisie arbitrairement ; cette routine positionne la variable 
« trace » h la valeur de son argument. 

15 Avec cette solution, la propriete de contt^Sle d'integrite d'execution est 
localement perdue entre le fragment d' execution qui precede le branchement 
et celui qui le suit, Mais elle reste globalement preservee sur T ensemble de 
r execution du programme* 

20 Cette methode peut plus gen6ralement s'appliquer a tons les points de forte 
convergence du flot de controle de la routine. 

Les subroutines, dans des langages comme ceux de la machine virtuelle 
«Java» (JVM) ou «Java Card» (JCVM) (marques deposees par Sun 
25 Mycrosystems), posent par exemple un probleme similaire. EUes peuvent en 
effet etre appelees depuis plusieurs points du code, avec des valeurs 
differentes pour Pempreinte. On peut les traiter de la meme maniere que les 
gestionnaires d'exception, en for9aiit la valeur de Tempreinte lorsqu'on entre 
dans une subroutine. Les points d' appels de subroutines etant bien delimites 
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sont codes explicitement par des app?ls de routine du type « adjustTrace(N) ». 
En outrej les ajustements auraient comme effet secondaire de rendre 
Tempreinte constante sur tout rintervalle dn code convert par un gestionnaire 
d" exception. L'empreinte serait done alors inefficace pour detecter les 
5 perturbations d' execution. 

Une solution a ce probleme est de forcer Tempreinte a une valeur connue 
statiquement lorsque Texecution entre dans un gestionnaire d'exceptions. Cela 
pent etre feit par Finterprete de la machine virtuelle, lorsqu'il traite le 
10 rattrapage d'une exception. Une autre possibilite est d'iaserer un appel a une 
routine « setTrace(T) » au debut de chaque gestionnaire d' exceptions, ou « T » 
est une valeur choisie arbitrairement ; cette routine positionne la variable 
« trace » a la valeui* de son argument. 

15 Avec cette solution, la propriete de controle d'integrite d' execution est 
localement perdue entre le fragment d' execution qui precede le branchement 
et celui qui le suit. Mais elle reste globalement preserv6e sur T ensemble de 
r execution du programme. 

20 Cette methode pent plus generalement s'appliquer a tous les points de forte 
convergence du flot de controle de la routine. 

Les subroutines, dans des langages comme ceux de la machine virtuelle 
«Java» (JVM) ou «Java Card» (JCVM) (marques deposees par Sun 
25 Mycrosystems), posent par exemple un probleme similaire. EUes peuvent. en 
effet etre appelees depuis plusieurs points du code, avec des valeurs 
difterentes pour Tempreinte. On pent les traiter de la meme maniere que les 
gestionnaires d'exception, en for^ant la valeur de l'empreinte lorsqu'on entre 
dans une subroutine. Les points d' appel s de subroutines etant bien deliniites 
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(par exemple, instructions « jsr » de la JVM et de la JCVM) et general ement 
assez pen nombreux, on pent aussi les traiter comme des branchements 
normauXj avec insertion d'appels a « adjustTrace >> avant les appels de 
subroutines pour garantir une meme valeur de Tempreinte en tous les points 
5 d'appel d'une meme subroutine. 

Par ailieurs, le calcul d'empreinte et son contrdle peuvent toujours 6tre limites 

a des fragments de code critiques du programme. Cela permet de reduire 
r accroissement en taille du code pour introduire la redondance que 

10 representent les operations sur les empreintes. Cela reduit egalement le 
ralentissement du aux calculs supplementaires du programme. 

Les operations sui^ les empreintes ne modifient pas le comportement du 
programme (en Tabsence de perturbation). Les operations de mise a jour 

15 d'^empreinte (du type « addTrace ») et d'ajustement d'empreinte (de type 
« adjustTrace ») se placent conceptuellement sur les arcs du graphe de flot de 
controle qui relie entre eux les points d'execution du programme, De cette 
maniere, la mise a jour d'empreinte et Tajustement peuvent dependre non 
seulement des points de programme parcourus en cours d"" execution mais aussi 

20 des branches specifiques suivies, y compris dans le cas ou plusieurs branches 
relient deux memes points. En pratique, dans le cas ou les operations de mise a 
jour et d'ajustement d'empreinte sont inserees effectivement dans le code 
executable du programme, elles sont disposees de maniere a etre executees en 
sequence entre les deux points de programme de Tare sur lesquelles elles sont 

25 placees. Cette insertion pent necessiter des modifications locales mineures du 
programme, comme Pajout de branchements supplementaires. 

En revanche, les operations d' affectation (de t3^pe « setTrace ») et de controle 

d'empreinte (de type' « checkTrace ») se placent conceptuellement sur les 
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(par exemple, instructions « jsr » de la JVM et de la JCVM) et generaiement 
assez peu nombreux, on pent aussi les traiter comme des branchements 
normaux, avec insertion d'appels a « adjustTrace » avant les appels de 
subroutines pour garantir une meme valeur de Tempreinte en tous les points 
d'appel d'une m6me subroutine. 

Par aiileurs, le calcul d'empreinte et son contrdle peuvent toujours etre limites 
^ des fragments de code critiques du programme. Cela pennet de reduire 
I'accroissement en taille du code pour introduire la redondance que 
repr6sentent les operations sur les empreintes. Cela reduit egalement le 
ralentissement du aux calculs supplementaires du programme. 

Les operations sur les empreintes ne modifient pas le comportement du 
programme (en I'absence de perturbation). Les operations de mise k jour 
d'empreinte (du type «addTrace») et d'ajustement d'empreinte (de type 
« adjustTrace ») se placent conceptuellement sur les arcs du graphe de flot de 
controle qui relie entre eux les points d'execution du programme. De cette 
mani^re, la mise a jour d'empreinte et I'ajustement peuvent dependre non 
seulement des points de programme parcourus en cours d'execution mais aussi 
des branches specifiques suivies, y compris dans le cas ou plusieurs branches 
relient deux mSmes points. En pratique, dans le cas ou les operations de mise a 
jour et d'ajustement d'empreinte sont inserees effectivement dans le code 
executable du programme, elies sont disposees de maniere a etre ex6cut6es en 
sequence entre les deux points de programme de I'arc sur lesquelles elles sont 
placees. Cette insertion peut necessiter des modifications locales mineures du 
programme, comme I'ajout de branchements supplementaires. 

En revanche, les operations d'affectation (de type « setTrace ») et de contrdle 
d'empreinte (de type « checkTrace ») se placent conceptuellement sur les 
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points de programme et noii sur les arcs entre ces points. La valeur de 
Pempreinte est en effet une propriete des points de programmes : quels que 
soient les cliemins d' execution menant a un point de programme donne, la 
valeur courante de Pempreinte (calculee dynamiquement) doit etre egale a une 
5 valeur fixe attendue (comiue statiquement) ; et cette valeur attendue pent etre 
forcee par une operation d' affectation d'empreinte. 

La valeur de Pempreinte en chaque point d' execution d'une routine de 
programme ainsi que les ajustements a inserer pour rendre previsible la valeur 
10 de Pempreinte peuvent etre determines automatiquement par une analyse 
statique de programme qui modifie eventueliement le code du programme 
pour rendre les empreintes previsibles et pour les controler. 



On se donne pour cela une routine du programme et des infoniiations 

15 concemant la mise a jour d'empreinte (points de programme et nature des 
obsei-vations de Pexecution en ce point de programme), P affectation 
d'empreinte (points de programme oiX Pempreinte doit 6tre forcee a certaines 
valeurs) et eventueliement le controle d'empreinte (points de programme ou 
Pempreinte doit etre controlee). 

20 

Les informations de mise a joui% d'affectation et de controle d'empreinte 
peuvent par'exemple etre donnees par des insertions explicites de directives 
(commentaires, pragmas^ code effectiveraent execute, etc.) dans le code du 
programme. De telles directives sont considerees de maniere neutre du point 
25 de vue du flot de controle du programme : les directives de mise a jour 
d'empreinte de type « addTrace » se piacent entre deux points d' execution 
effectifs (hors directives) du programme, et ainsi sur les arcs qui relient 
conceptuellement entre eux les points d' execution du programme ; les 
directives d' affectation (« setTrace ») et de controle d'empreinte 
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points de programme et non sur les arcs entre ces points. La valeur de 
I'empreinte est en effet une propriete des points de programmes : quels que 
soient les chemins d' execution menant a un point de programme donne, la 
valeur courante de I'empreinte (calculee dynamiquement) doit etre egale k une 
valeur fixe attendue (connue statiquement) ; et cette valeur attendue peut atre 
forcee par une operation d' affectation d'empreinte. 

La valeur de I'empreinte en chaque point d'execution d'une routine de 
programme ainsi que les ajustements k insurer pour rendre previsible la valeur 
de I'empreinte peuvent etre determines automatiquement par une analyse 
statique de programme qui modifie eventuellement le code du programme 
pour rendre les empreintes previsibles et pour les contrdler. 

On se donne pour cela une routine du programme et des informations 
concernant la mise a jour d'empreinte (points de programme et nature des 
observations de 1' execution en ce point de programme), 1' affectation 
d'empreinte (points de programme ot I'empreinte doit etre forcee a certaines 
valeurs) et eventuellement le controle d'empreinte (points de programme oii 
I'empreinte doit Stre controlee). 



Les informations de mise a jour, d'affectation et de controle d'empreinte 
peuvent par exemple etre donn6es par des insertions explicites de directives 
(commentaires, pragmas, code effectivement execute, etc.) dans le code du 
programme. De telles directives sont considerees de manidre neutre du point 
de vue du flot de controle du programme : les directives de mise a jour 
d'empreinte de type « addTrace » se placent entre deux points d'execution 
effectifs (hors directives) du programme, et ainsi sur les arcs qui relient 
conceptuellement entre eux les points d'execution du programme; les 
directives d'affectation («setTrace») et de controle d'empreinte 
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(« checkTrace ») portent sur le point d' execution qui suit. II en va de meme 
pour les directives eventuellement inserees par la transformation de 
progi-amme : les directives d'ajustement de type « adjustTrace » sont 
egalement neutres et se placent sur les arcs (pour comger la valeur d'une 
5 empreinte avant d'atteindre un point de programme), c'est-a-dire entre deux 
points d' execution. 

Les directives d' affectation d' empreinte peuvent avoir etc placees par une 
transformation de programme prealable. Cette transformation pent par 
10 exemple systematiquement placer une directive de type « setTrace » en tons 
les points de programme ou conflue un nombre de branches d' execution 
superieur a un seuil donne. De telles directives peuvent egalement etre placees 
systematiquement a tons les points d' entree des subroutines et/ou des 
gestionnaires d' exception. 

15 

De meme, les valeurs manipulees pat^ les directives de mise a jour d' empreinte 
peuvent aussi avoir ete determinees par une trans fomiation de programme 
prealable. En effet, les valeurs utilisees pour cette mise a jour (argument de 
« addTrace ») sont en general des constantes arbitraires. Une valeur 

20 quelconque (par exemple aleatoire) pent done etre automatiquement attribuee 
a chaque occurrence d'une telle directive. Dans certains cas, on pent aussi 
vouloir exploiter des invariants du programme. On precede aiors a une analyse 
statique du programme afm de determiner des invariants en certains points de 
programme, par exemple le fait que la somme de deux variables est constante 

25 le fait qu'une variable est inferieure a un certain seuil, le fait que le nombre de 
tours de boucle est connu, etc. Ensuite, au lieu de mettre a jour T empreinte en 
fonction de constantes, on emploie des expressions qui, bien qu'elles portent 
sur des donnees dynamiques du programme, doivent avoir une valeur 
constante. 

30 
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(« checkTrace ») portent sur le point d'execution qui suit. II en va de meme 
pour les directives eventuellement inserees par la transfoi-mation de 
programme : les directives d'ajustement de type « adjustTrace » sont 
egalement neutres et se placent sur les arcs (pour corriger la valeur d'une 
empreinte avant d'atteindre un point de programme), c'est-a-dire entre deux 
points d' execution. 

Les directives d' affectation d' empreinte peuvent avoir ete placees par une 
transformation de programme prealable. Cette transformation peut par 
exemple systematiquement placer une directive de type « setTrace » en tous 
les points de programme ou conflue un nombre de branches d' execution 
superieur a un seuil donne. De telles directives peuvent egalement etre placees 
systematiquement a tous les points d' entree des subroutines et/ou des 
gestionnaires d' exception, 

De ni6nie, les valeurs manipulees par les directives de tnise a jour d' empreinte 
peuvent aussi avoir ete d6termin6es par une transformation de programme 
prealable. En efifet, les valeurs utilis6es pour cette mise a jour (argument de 
«addTrace») sont en general des constantes arbitraires. Une valeur 
quelconque (par exemple aleatoire) peut done atre automatiquement attribuee 
a chaque occurrence d'une telle directive. Dans certains cas, on peut aussi 
vouloir exploiter des invariants du programme. On procede alors a une analyse 
statique du programme afin de determiner des invariants en certains points de 
programme, par exemple le fait que la somrae de deux variables est constante 
le fait qu'une variable est inferieure a un certain seuil, le fait que le nombre de 
tours de boucle est connu, etc. Ensuite, au lieu de mettre ^ jour I'empreinte en 
fonction de constantes, on emploie des expressions qui, bien qu'elles portent 
sur des doimees dynamiques du programme, doivent avoir une valeur 
constante. 
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(« checkTrace ») portent sur le point execution qui suit. II en va de meme 
pour les directives eventuellement inserees par la transformation de 
programme : les directives d'ajustement de type « adjustTrace » sont 
egalement neutres et se placent sur les arcs (pour corriger la valeur d'une 
5 empreinte avant d'atteindre un point de programme), c'est-a-dire entre deux 
points d' execution. 



Les directives d'affectation d'empreinte peuvent avoir ete placees par une 
transformation de programme prealable. Cette transfomiation peut par 
1 0 exemple systematiquement placer une directive de type « setTrace » en tous 
les points de programme ou conflue un nombre de branches d' execution 
superieur a un seuil domie. De telles directives peuvent egalement etre placees 
systematiquement a tous les points d' entree des subroutines et/ou des 
gestionnaires d' exception. 

15 

De meme, les valeurs manipulees par les directives de raise a jour d'empreinte 
peuvent aussi avoir ete determinees par une transformation de programme 
prealable. En effet, les valeurs utilisees pour cette mise a jour (argument de 
« addTrace ») sont en general des constantes arbitraires. Une valeur 

20 quelconque (par exemple aleatoire) peut done etre automatiquement attribuee 
a chaque occurrence d'une telle directive. Dans certains cas, on peut aussi 
vouloir exploiter des invariants du programme. On procede alors a une analyse 
statique du programme afin de determiner des invariants en certains points de 
programme, par exemple le fait que la somme de deux variables est constante 

25 le fait qu'une variable est inferieure a un certain seuil, le fait que le nombre de 
tours de boucle est connu, etc. Ensuite, au lieu de mettre a jour T empreinte en 
fonction de constantes, on emploie des expressions qui, bien qu'elles portent 
sur des donnees dynamiques du programme, doivent avoir une valeur 
constante. 

30 
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Le precede de detemunation automatique des valeurs d'empreinte attendues 
est ensuite defini par la sequence operatoire suivante. 

@ Initialisation de T ensemble des points de programme a explorer au 
singleton constitue de la premiere instruction de la routine. 

® Memorisation au point d'entree de la routine d'une valem' d'empreinte 
egale a la valeur initiale donnee de Tempreinte, 

® Tant que ledit ensemble des points de programme a explorer n*est pas 
vide : 

- Extraction d'un point de programme (le point d'origine) dudit ensemble 
des points de programme a explorer. 

- Pour chacun des points de programme resultants possibles apres 
execution de Finstruction (les points cibles) : 

Si le point cible comporte une affectation d'empreinte et si ce point 
cible n'a pas encore ete explore, memorisation au point cible de la 
valeur d' empreinte definie par 1 ' affectation. 

Si le point cible ne comporte pas d' affectation d' empreinte et si ce 
point cible a,,deja ete explore, insertion entre Tinstruction au point 
d'origine et Tinstruction au point cible d'un ajustement d'empreinte 
qui envoie la valeur de Tempreinte au point d'origine sur la valeur 
de r empreinte memorisee au point cible. 

Si le point cible ne comporte pas d'affectation d'empreinte et si ce 
point cible n^a pas encore ete explore, memorisation au point cible 
de la valeur de Tempreinte au point d'origine, eventuellement 
modifiee par une mise a jour empreinte s'il y en a une entre le 
point d'origine et le point cible. 

Si le point cible n'a pas encore ete explore, ajout dudit point cible dans 
ledit ensemble des points de programme t explorer. 
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Le precede de determination automatique des valeyrs d'empreinte attendues 
est ensuite defini par la sequence operatoire suivante. 

• Initialisation de Pensemble des points de programme a explorer au 
singleton constitue de la premiere instruction de la routine. 

® Memorisation au point d'entree de la routine d'une valeur d'empreinte 
egale a la valeur initiale donnee de I'empreinte. 

@ Tant que ledit ensemble des points de programme a explorer n'est pas 
vide : 

- Extraction d'un point de programme (le point d'origine) dudit ensemble 
des points de progi-amme h explorer. 

- Pour chacun des points de programme resultants possibles aprds 
execution de 1' instruction (les points cibles) : 

Si le point cible comporte une affectation d'empreinte et si ce point 
cible n'a pas encore ete explore, memorisation au point cible de la 
valeur d'empreinte definie par 1' affectation. 

Si le point cible ne comporte pas d'affectation d'empreinte et si ce 
point cible a dej^ ete explore, insertion entre I'instruction au point 
d'origine et Tinstruction au point cible d'un ajustement d'empreinte 
qui envoie la valeur de I'empreinte au point d'origine sur la valeur 
de I'empreinte memorisee au point cible. 

Si le point cible ne comporte pas d'affectation d'empreinte et si ce 
point cible n'a pas encore ete explore, memorisation au point cible 
de la valem- de I'empreinte au point d'origine, eventuellement 
modifiee par une mise a jour d'empreinte s'il y en a une entre le 
point d'origine et le point cible. 

Si le point cible n'a pas encore ete explore, ajout dudit point cible dans 
ledit ensemble des points de programme a explorer. 
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Certains iangages ne permettent pas de manipuler facilement des directives 
neutres du type des directives de prise et de controle d'.empreinte decrites ci- 
dessus. On pent employer dans ce cas ime technique qui consiste a 
instrumenter le code du programme avec des instructions reelles. 

Par exemple, on pent inserer dans le code du programme des appels de routine 
explicites, aussi bien pour la mise k jour d'empreinte et T affectation 
d'empreinte que pour le controle d'empreinte. Par exemple, on peut ecrire en 
« Java »: 

{ 

» » • 

if (cond) { 

a[i+j]=b[i]; 
addTraceO; 

> 

checkTraceQ; 

} 

catch (Exception e) { 
setTraceQ; 
• • » 

} 

Ce fragment de programme peut etre transforme une premiere fois pour 
r attribution de valeurs d'empreinte arbiti^aires pour les operations de mise a 
jour et d' affectation : 
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Certains langages ne permettent pas de manipuler facilement des directives 
neutres du type des directives de prise et de controle d'empreinte decrites ci- 
dessus. On peut employer dans ce cas une technique qui consiste a 
instramenter le code du programme avec des instructions reelles. 



Par exemple, on peut inserer dans le code du programme des appels de routine 
explicites, aussi bien pour la mise a jour d'empreinte et T affectation 
d^empreinte que pour le controle d^empreinte. Par exemple, on peut ecrire en 



« Java »: 



10 { 



if (cond) { 



a[i+j] = b[i]; 
addTraceO; 



15 } 



checkTraceO; 



} 



catch (Exception e) { 
setTraceQ; 



} 

Ce fragment de programme peut etre transforaie une premiere fois pour 

Tattribution de valeui^s d'empreinte arbitraires pour les operations de mise a 
jour et d' affectation : 
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{ 

• • • 

if (cond) { 

a[i+j] = b[i]; 
addTrace(28935); 

} 

checkTrace(): 

} 

catch (Exception e) { 
setTrace(9056); 

mm* 

} 

Puis, ie programme peut etre traasforme une seconde fois selon le precede 
decrit ci-dessus pour determiner les valeurs d'empreinte aux points de controle 
15 et pour inserer les ajustements necessaires. Les valeurs attribuees par cette 
transformation dependent de I'operateur de hachage utilise. Le fragment de 
programme donne en exemple ci-dessus pourra 6tre transforme ainsi : 
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{ 

• • a 

if (cond) { 

a[i+j] = b[i]; 
adciTrace(28935); 

} 

checkTraceQ; 

} 

catch (Exception e) { 
setTrace(9056); 
» * ♦ 

} 

Puis, le programme peut etre transforme une seconde fois selon le precede 
decrit ci-dessus pour detemiiner les valeurs d'empreinte aux points de controle 
et pour inserer les ajustements necessaires. Les valeurs attribuees pai^ cette 
transformation dependent de Toperateur de hachage utilise, Le fragment de 
programme donne en exemple ci-dessus pourra etre transforme ainsi : 
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{ 

■ ■ » 

if (cond) { 

a[i+j] = b[i]; 
addTrace(28935); 
adjustTrace( 1 6220); 

} 

ch.eckTrace( 13991); 

} 

catch (Exception e) { 
setTrace(9056); 
• t * 

} 

Si Ton veut pouvoir compiler et executer le programme avaxit transformations^ 
par exemple pour le mettre au point, il pent falloir adapter le programme 
source. En effet, si la Hbrairie de prise et de controle d'empreinte ne comporte 
que des routines qui prennent en argument un entier, il est illegal d'ecrire 
« checkTraceQ ». Dans ce cas, on pent adopter la convention suivante : la 
yaleur « 0 » (par exemple) denote une valeur encore indeterminee. On ecrit 
alors « checkTrace(O) » dans le code source initial. Apres transformation, 
Tappel de routine deviendra par exemple « checkTrace(13991) ». 

Cette technique est compatible avec la compilation, du. programme : les 

transformations de prograjinme peuvent se faire aussi bien sur le code source 
que sur le code objet. Par exemple, en « Java Card », on pent ecrire : 

checkTrace(O) ; 
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{ 

» • • 

if (cond) { 

a[i+j]=b[i]; 
addTrace(28935); 
adjustTrace( 1 6220); 

} 

checkTrace( 1 3 99 1 ); 

} 

catch (Exception e) { 
setTrace(9056); 
• * » 

} 

15 Si Ton veut pouvoir compiler et executer le programme avant transformations, 
par example pour le mettre au point, il pent falloir adapter le programme 
source. En effet, si la librairie de prise et de contrdle d'empreinte ne comporte 
que des routines qui prennent en argument un entier, il est illegal d'ecrire 
« checkTraceQ ». Dans ce cas, on pent adopter la convention suivante : la 

20 valeur « 0 » (par exemple) denote une valeur encore indeterminee. On ecrit 
alors « checkTrace(O) » dans le code source initial Apres transformation^, 
Tappel de routine deviendrapar exemple « checkTrace( 13991) ». 

Cette technique est compatible avec la compilation du programme : les 
25 transformations de programme peuvent se faire aussi bien sur le code source 
que sui' le code objet. Par exemple, en « Java Card », on pent ecrire : 

checkTrace(O) ; 
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Apres compilation et conversion au format d'execution de la JCVM, on a un 
code objet de la forme : 

sconst_0 

invokestatic checkTrace 

Le precede de determination automatique de la valeur attendue de I'empreinte 
au moment du « invokestatic » peut s'appliquer au code objet de la JCVM et 
produire le code suivant : 

sspush 13991 
invokestatic checkTrace 

Ce precede de determination automatique des valeurs d'empreinte peut etre 
combine k une analyse de programme qui effectue dans certaines cas un 
derouiage des boucies et recursions du programme. On peut alors calculer 
automatiquement des empreintes qui portent sur des variables du programme, 
comme dans I'exemple ci-dessus ou « trace = h(trace, i) » figure a Pinterieur 
de la boucle d'indice « i ». 

L'empreinte peut 6tre calculee comme indique ci-dessus a partir de points 
d'observation donnes inseres explicitement dans le code du programme. 
L'empreinte peut aussi etre calculee automatiquement et implicitement par 
I'inteiprete d'une machine virtuelle. 

En particulier, l'empreinte peut porter sur le code des instructions executees 
par la machine virtuelle, Elle permet ainsi de contrdler que I'execution 
successive des instructions du programme n'estpas perturbee. 

La boucle principale de I'interprete d'une machine virtuelle a generalement la 
fomie suivante : 
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Apres compilation et conversion au format d' execution de la JCVM, on a un 
code objet de la forme : 

sconst_0 

invokestatic checkTrace 

Le procede de determination automatique de la valeur attendue de I'empreinte 
au moment du « invokestatic » pent s'appliquer au code objet de la JCVM et 
produire le code suivant : 

sspush 13991 

invokestatic checkTrace 

Ce procede de determination automatique des valeurs d'empreinte peut etre 
combine a une analyse de programme qui effectue dans certaines cas un 
deroulage des boucles et recursions du programme. On peut alors calculer 
automatiquement des empreintes qui portent sur des variables du programme, 
comme dans I'exemple ci-dessus oil « trace = h(trace, i) » figure A I'interieur 
de la boucle d'indice « i ». 

L'empreinte peut 6tre calculee comme indique ci-dessus a partir de points 
d' observation doimes inseres explicitement dans le code du programme. 
L'empreinte peut aussi 6tre calcul6e automatiquement et implicitement par 
I'interprete d'une machine virtuelle. 

En particulier, I'empreinte peut porter sur le code des instructions executees 
par la machine virtuelle. Elle permet ainsi de controler que 1' execution 
successive des instructions du programme n' est pas perturb^e. 

La boucle principale de I'interprete d'une machine virtuelle a generalement la 
forme suivante : 
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while (1) { 

// Lecture du code de F instruction a Tadresse pc 
opcode = *pc++; 
switch (opcode) { 
5 case INSTR : 

// Semantique de ['instruction « instr » 

* w * 

} 

} 

10 On peut instrumenter ce code ainsi : 

while (1) { 

opcode = *pc++; 
addTrace(opcode) ; 
switch (opcode) { 

15 

} 

} 

Pour le moment, on suppose que la variable « trace » associee a T operation 
20 « addTrace » est, a chaque appel de routine, sauvegardee dans le bloc 
deactivation de la routine appelante et reinitialisee a une valeur connue « To >>, 
et qu'elle est symetriquement restauree depuis le bloc deactivation de 
r appelant a chaque retour de routine. Ainsi, en un point quelconque du 
programme, la valeur de « trace » est « Tn h(. . .h(h(To, ii), ia)- • • * in) qui est 
25 Tempreinte des codes operatoires «ii, ...,in» des instructions executees 
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while (1) { 



// Lecture du code de rinstruction k I'adresse pc 
opcode = ="pc-l-i-; 
switch (opcode) { 
case INSTR : 

// Semantique de 1' instruction « instr » 



} 



} 



10 On peut instrumenter ce code ainsi : 

while (1) { 

opcode == '^pc++; 
addTrace(opcode); 
switch (opcode) { 



} 



} 



Pour le moment, on suppose que la variable « trace » associee a T operation 
20 « addTrace » est, a chaque appel de routine, sauvegardee dans le bloc 
deactivation de la routine appelante et reinitialisee a une valeur connue « Tq », 
et qu'elle est symetriquement restauree depuis le bloc d' activation de 
r appelant a chaque retour de routine. Ainsi, en un point quelconque du 
programme, la valeur de « trace » est « Tn = h(. , .h(h(To, ii), 12)^ « in) »s> qui est 
25 Tempreinte des codes operatoires «ii, ...jin)) des instructions executees 
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depuis r entree dans la routine courante, en ignorant les instructions des 
m6thodes appelees. 

Cette mise a jour d*empreinte implicite pent etre prise en compte 
explicitement et automatiquement par le precede decrit ci-dessus de 
. determination automatique des valeurs d'empreinte attendues. Des invariants 
du programme visible au niveau de la machine virtuelle peuvent en outre etre 
utilises pour la mise a jour d'empreinte : hauteur de la pile d'operande, 
presence de valeurs de certains types dans la pile d'operande (si la pile est 
typee ou si les doiin^es permettent d'identifier leur type) 

Le modele de calcul d'empreinte implicite par une machine virtuelle se 
transpose directement au cas d'un microprocesseur executant du code natif. Le 
microprocesseur doit pour cela etre confu pour tenir a jour Tempreinte pour 
chaque instruction executee. Dans cette approche, la variable « trace » devient 
un registre special du processeur, accede via des instructions de type « load » 
et « store » (pour sauver et restaurer la valeur de la trace a I'entree et k la sortie 
des procedures), « addi » et « movi » (pour corriger et initialiser la valeur de la 
trace). 

D'un point de vue pratique, la prise d'empreinte doit etre realisee de maniere a 
ralentir au minimum le chemin critique du processeur. Ce peut Btre egalement 
un mode de fonctionnement d^brayable du processeur, qui permet de 
n'effectuer les calculs d'empreinte que dans des sections critiques du code. 

Un debrayage dynamique de ce type peut egalement 6tre mis en ceuvre dans le 
cadre d'un calcul d'empreinte implicite par une machine virtuelle. 

Une autre possibilite pour accelerer le calcul d'empreinte est que le processeur 
dispose d'une instruction qui effectue I'operation de mise a jour 
« trace = h(trace, x); » en hardware. Cette instruction machine peut etre 



7 



regue le 08/01/04 

-22- 



depuis 1' entree dans la routine courante^ en ignorant les instructions des 
methodes appelees. 

Cette mise a jour d'empreinte implicite peut etre prise en compte 
5 explicitement et automatiquement par le procede deer it ci-dessus de 
determination automatique des valeurs d'empreinte attendues. Des invariants 
du programme visible au niveau de la machine virtuelle peuvent en outre etre 
utilises pour la mise a jour d'empreinte : hauteur de la pile d'operande^ 
presence de valeurs de certains types dans la pile d'operande (si la pile est 
10 typee ou si les donnees perraettent d'identifier leur type) 

Le modele de calcul d'empreinte implicite par une machine virtuelle se 
transpose directement au cas d'un microprocesseur executant du code natif, Le 
microprocesseur doit pour cela etre con9U pour tenir a jour Tempreinte pour 
15 chaque instruction ex^cutee. Dans cette approche, la variable « trace » devient 
im registre special du processeur^ accede via des instructions de type « load » 
et « store » (pour sauver et restaurer la valeur de la trace a T entree et a la sortie 
des procedures), « addi » et « movi » (pour corriger et initialiser la valeur de la 
trace). 

20 D'mi point de vue pratique, la prise d'empreinte doit etre realisee de maniere a 
ralentir au minimum le chemin critique du processeur. Ce peut etre egalement 
un mode de fonctionnement debrayable du processeur, qui permet de 
n'effectuer les calculs d'empreinte que dans des sections critiques du code. 

Un debrayage dynamique de ce type peut egalement etre mis en oeuvre dans le 
25 cadre d'un calcul d'empreinte implicite par une machine virtuelle, 

Une autre possibilite pour accelerer le calcul d'empreinte est que le processeur 
dispose d'une instruction qui effectue I'operation de mise a jour 
« trace = h(trace, x); » en hardware. Cette instruction machine peut eti'e 
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utilisee aussi bien dans la boucle d'inteipretation d'une machine virtuelle que 
dans du code natif, ou elle peut etre inseree a"utomatiquement par 
transformation du code machine. Le processeur peut comporter egalement des 
instructions dediees pour effectuer les operations d'ajustements, d' affectations 
5 et de contrdle d'empreinte. 

De telles instructions specialisees peuvent egalement etre explicitement 
incluses dans le jeu d'instruction d'une machine virtuelle : au lieu d'operer 
explicitement siir xme variable « trace » ou de faire des appels de routine du 
10 type « addTrace(N) », « setTrace(T) », « adjustTrace(N) » et 
« checkTrace(T) », ces operations peuvent etre realisees par des instructions 
dediees de la machine virtuelle. Le calcul d'empreinte n'est pas dans ce cas 
implicite : il est explicite et necessite une instrumentation (eventuellement 
automatique) du progi'amme. 

L'interet d'une telle approche est non seulement un gain en vitesse mais aussi 
en tailie memoire, Ainsi, par exemple, au lieu des six octets que requierent 
Tappel « checkTrace(42) » dans du code objet JCVM, seuls trois octets (un 
pour Pinstruction et deux pour Targument entier court) seraient necessaires. 

20 Dans le cas ou Tempreinte est mise a jour automatiquement et implicitement 
pai' la machine d' execution (machine virtuelle ou processeur), plusieurs 
perfectionnements sont envisageables. 

Tout d'abord, pour diminuer le surcout en temps d'execution du a la prise 
25 d'empreinte, on peut envisager de ne pas modifier Tempreinte pour certaines 
classes d' instructions. Ceci peut s'effectuer a Taide d'une table qui associe a 
tout code d'instruction un booleen qui indique si Pinstruction est a tracer. La 
boucle principale de I'interprete s'ecrit alors de la maniere suivante : 
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utilisee aussi bien dans la boucle d' interpretation d'une machine virtuelle que 
dans du code natif, ou elle pent dtre ins6ree automatiquement par 
transformation du code machine, Le processeur pent comporter egalement des 
instructions dediees pour effectuer les operations d'ajustements, d' affectations 
5 et de controle d'empreinte, 

De telles instructions speciahsees peuvent egalement etre explicitement 
incluses dans le jeu d^instruction d'une machine virtuelle : au lieu d'operer 
explicitement sur une variable « trace » ou de faire des appels de routine du 
10 type « addTrace(N) », « setTrace(T) « adjustTrace(N) » et 

« checkTrace(T) ces operations peuvent etre realisees par des instructions 
dediees de la machine virtuelle. Le calcul d'empreinte n'est pas dans ce cas 
implicite : il est explicite et necessite une instrumentation (eventuellement 
automatique) du programme. 

L'interet d'une telle approche est non seulement un gain en vitesse mais aussi 
en taille memoire. Ainsi^ par exemple, au lieu des six octets que requierent 
Tappel « checkTrace(42) » dans du code objet JCVM, seuls trois octets (un 
pour rinstruction et deux pour T argument entier court) seraient necessaires. 

20 Dans le cas ou Tempreinte est mise a jour automatiquement et implicitement 
par la machine d' execution (machine virtuelle ou processeur), plusieurs 
perfectionnements sont envisageables. 

Tout d'abord, pour diminuer le surcout en temps d'execution du a la prise 
25 d'empreinte, on pent envisager de ne pas modifier Tempreinte pour certaines 
classes d' instructions. Ceci peut s'effectuer a Taide d'une table qui associe a 
tout code d'instruction un booleen qui indique si Tinstruction est a tracer. La 
boucle principale de Tinterprete s'ecrit alors de la maniere suivante : 
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while (1) { 



opcode = *pc++; 



if (update_trace[opcode]) 



trace = h(trace^ opcode); 



5 



switch (opcode) { 



10 L' information des instructions a effectivement tracer (ici le tableau 
« update_trace ») peut accompagner le programme lors de son chargement et 
de son execution sur la plate-forme d' execution, Cette information peut en 
' outre varier suivant les programmes et meme suivant les differentes routines 
des differ ents programmes. 



On peut egalement coder cette information « en dur » dans Pinterprete pour 
les .cas correspondahts aux differents codes d' instruction. On a ainsi par 
exemple : 
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while (1) { 



opcode = *pc++; 

if (update_trace[opcode]) 

trace = h(tracej, opcode); 
switch (opcode) { 



s 



X 



10 L'infoiination des instractions a effectivement tracer (ici le tableau 
« update_trace ») peut accompagner le programme lors de son chargement et 
de son execution sur la plate- forme d' execution. Cette information peut en 
outre varier suivant les programmes et m6me suivant les differentes routines 
des differents programmes. 

15 

On peut egalement coder cette information « en dur » dans Tinterprete pour 

^ les cas coiTespondants aux differents codes d'instmction. On a ainsi par 
exemple : 
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while (1) { 



opcode = *pc++; 
switch (opcode) { 



case INSTRl : // tracee 



trace = h(trace, opcode); 



case INSTR2 : // pas tracee 
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10 



} 



} 



Poxjr detecter d'eventuelles pertobations sur la valeur des arguments 
inmiediats des instructions, on peut 6galement les integrer dans le calcul de 
I'empreinte. Par exemple, dans le cas de la JCVM, pour I'instruction 
15 «bspushn» (qui pousse la constante entiere «n» siir la pile d'operande), 
I'interprete peut effectuer « trace = h(h(trace, BSPUSH), n) » au lieu de 
simplement « trace = h(trace, B SPUSH) » . 

Pour conserver la possibilite de calculer statiquement les valeurs d'empreintes, 
20 ce schema ne peut Sti-e applique qu'aux instructions dont les arguments 
immediats ne sont pas modifies au moment du chargement, a F edition de lien. 
Dans le cas contraire, il faut atre capable d'operer sur le programme apres 
edition de lien. C'est par exemple possible dans le cas ou le programme est 
inclus en memoire morte (ROM) dans un masque de carte k puce. 

25 

Pour rendre la valeur de I'empreinte encore plus sensible au flot de controle 
effectivement suivi a I'interieur du code d'une routine, les instructions de 
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while (1) { 

opcode = *pc-H-; 
switch (opcode) { 
case INSTRl : // tracee 

trace = h(trace, opcode); 

a • • 

case INSTR2 : // pas tracee 

« a « 

} 

} 

Pour detecter d'^ventuelles perturbations sur la valeur des arguments 
iramediats des instructions, on peut 6galement les int^grer dans le calcul de 
I'empreinte. Pai- exemple, dans le cas de la JCVM, pour i'instmction 
«bspushn» (qui pousse la constante entiere «n» sur la pile d'operande), 
I'interprete peut effectuer « trace = h(li(trace, BSPUSH), n) » au lieu de 
simplement « trace = h(trace, BSPUSH) ». 

Pour conserver la possibilite de calculer statiquement les valeurs d'empreintes, 
ce schema ne peut etre applique qu'aux instructions dont les arguments 
immediats ne sont pas modifies au moment du chargement, a I'edition de lien. 
Dans le cas contraire, il faut etre capable d'operer sur le programme apr^s 
edition de lien. C'est par exemple possible dans le cas ou le programme est 
inclus en memoire morte (ROM) dans un masque de carte a puce. 

Pour rendre la valeur de I'empreinte encore plus sensible au flot de contr61e 
effectivement suivi a I'interieur du code d'une routine, les instructions de 
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branchement conditiomiel (par exemple « ifzero » dans la JCVM) et de 
branchement multiple (par exemple « stableswitch » dans la JCVM) peuvent 
mettre a jour la trace de maniere differente suivant que le branchement 
conditionnel est pris ou non, ou suivant T entree de la table de saut qui est 
5 selectionnee. Par exemple : 

switch (opcode) { 

case IFZERO: 

if (top_of_stack === 0) { 

trace = h(trace, BRANCH^TAKEN); 



15 




10 pc4-pc[0]; 



} else { 



trace = h(trace, BRANCH_NOT_TAKEN); 
pc += 1; 



} 



On pent aussi voir ce perfectionnement comme la prise en compte de la valeur 
connue de T expression « top_of_stack 0 » dans chacune des branches de 
rinstruction « ifzero », c'est-a-dire respectivement « true » et « false ». 



20 Dans ce qui a ete decrit jusqu'a present, Tempreinte est calculee routine par 
routine. II est inutile, et potentiellement couteux en temps d'execution, de 
mettre a jour la variable « trace » lors de T interpretation de routines qui ne 
vont jamais consulter la valeur de cette variable, c'est-a-dire qui ne 
contiennent pas d'operations de type « checkTrace ». LMnformation indiquant 

25 si* une routine contient une operation « checkTrace » pent facilement etre 
determine peu* un simple examen du code de la routine. 
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branchement conditionnel (par exemple « ifzero » dans la JCVM) et de 
branchement multiple (par exemple « stableswitch » daiis la JCVM) peuvent 
mettre a jour la trace de maniere differente suivant que le branchement 
conditionnel est pris ou non, ou suivant 1' entree de la table de saut qui est 
selectioimee. Par exemple : 

switch (opcode) { 

case IFZERO: 

if (top_of_stack == 0) { 

trace = h(trace, BRANCH_TAKEN); 

pc+=pc[0]; 

} else { 

trace = h(trace, BRANCH_NOT_TAKEN); 

pc += 1 ; 

} 

• • • 

On peut aussi voir ce perfectionnement comme la prise en compte de la valeur 
connue de I'expression « top_of_stack = 0 » dans chacune des branches de 
rinsti-uction « ifeero », c'est-a-dire respectivement « true » et « false ». 

Dans ce qui a et6 decrit jusqu'a present, I'empreinte est calculee routine par 
routine. II est inutile, et potentiellement couteux en temps d'execution, de 
mettre a jour la vaiiable « trace » lors de 1' interpretation de routines qui ne 
vont jamais consulter la valeur de cette variable, c'est-a-dire qui ne 
contiennent pas d' operations de type « checkTrace ». L' information indiquant 
si une routine contient une operation « checkTrace » peut facilement dtre 
determine par un simple examen du code de la routine. 
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L'interprete de la machine virtuelle peut alors etre modifie comme suit : 
while (1) { 

opcode = *pc-H-; 

if (method_flags & NEEDS_TRACE) 
5 trace = h(trace, opcode); 

switch (opcode) { 
« » ■ 
} 

} 

10 

Dans le cas particulier de la JCVM, cette information peut par exemple etre 
calculee un fois pour toute (par exemple au cliargement du programme) et 
enregistree sous foraie d'un bit dans le champ « flags » de la structure 
« method_info ». 

15 

■ JusquMci, on a considere Tempreinte d'execution comme locale a chaque 
methode : la variable « trace » est preservee a Tappel de routine, et sa vaieur 
represente une empreinte des points d'observation de Texecution a Tinterieur 
de la routine courante, en excluant les routines appelees. La variable « trace » 
20 peut etre rendue globale, et done contenir une empreinte de toutes les 
instructions ex6cutees, y compris a travers des appels de routines, depuis des 
points d'entree connus (par exemple, les methodes « process » et « install » 
d'une applet « Java Card »), ou « trace » a ete initialisee a des valeurs 
connues. 

25 

Les motivations sont doubles : d'une part la possibilite de verifier en une seule 

operation « checkTrace » Tabsence de perturbations dans Texecution 
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L'interprete de la machine virtuelle peut alors etre modifie comme suit : 
while (1) { 

opcode = '^'•po-\r+; 

if (method_flags & NEEDS^^TRACE) 
5 toce = h(trace5 opcode); 

switch (opcode) { 

» » • 

} 

} 

10 

Dans le cas particulier de la JCVM, cette information peut par exemple etre 
calculee un fois pour toute (par exemple au chargement du programme) et 
enregistree sous forme d'un bit dans le champ « flags » de la stmcture 
« method_info », 

15 

JusquMcij on a considere Tempreinte d' execution comme locale a chaque 
methode : la variable « trace » est preservee a Pappel de routine, et sa valeur 
repr6sente une empreinte des points d' observation de T execution a Finterieur 
de la routine courante^ en excluant les routines appelees. La variable « trace » 
20 peut etre rendue globale, et done contenir une empreinte de toutes les 
instructions executees, y compris a travers des appels de routines, depuis des 
points d' entree connus (pax exemple, les methodes « process » et « install » 
d'une applet «Java Card»), ou « trace » a ete initialisee a des valeurs 
connues. 

25 

Les motivations sont doubles : d'une part la possibilite de verifier en une seule 
operation « checkTrace » F absence de perturbations dans F execution 
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complete du programme, et noa pas juste dans Pexecution de la routine ou se 
trouve le « checkTrace » ; et d'autre part, dans le cas ou Tempreinte est prise 
implicitement par la machine d' execution, la simplification de cette machine 
(plus besoin de sauvegarder et de restaurer « trace » a chaque appel), 

5 La principale difficulte de cette approche est le calcul statique des valeurs de 
Fempreinte en tout point du programme. Ce calcul reste possible^ mais exige 
ou bien une analyse du programme complet (interprocedurale), ou bien 
Tetablissement d'invariants sur les valeurs de Tempreinte au debut et a la fin 
de chaque routine. 

10 

Dans Tapproche par analyse globale, on suppose connaitre, au moment de 
r analyse statique, le code de toutes les routines pouvant etre appelees 
directement ou indirectement a partir des points d'entree du programme, y 
compris les routines appartenant a d'autres programmes, en particulier celles 
15 de librairies. 



Sous cette hypothese, le precede de determination statique de Tempreinte 
decrit ci-dessus s'etend comme suit: au lieu d' analyser et de transformer 
chaque routine individuellement, on les transforme toutes en meme temps, en 
20 traitant les instructions d'appel de routines (« invoke », « call », etc) comme 
des branchements inconditionnels a la premiere instruction de la routine 
appelee, et les instructions de retour d'appel (« return », etc.) comme des 
branchements vers les instructions suivant immediatement Tappel 
correspondant. 

25 

En d'autres termes, on travaille non plus sur le graphe de flot de controle de la 
routine, mais sur le gi*aphe de flot de controle interprocedural, contenant des 
arcs supplementaires coiTespondant aux instructions d'appel et de retour de 
routine. On notera que pour les instructions qui deteraiinent dynamiquement la 
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complete du programme, et non pas juste dans Tex^cution de la routine ou so 
trouve le « checkTrace » ; et d'autre part, dans le cas ou Tempreinte est prise 
implicitement par la machine d' execution, la simplification de cette machine 
(plus besoin de sauvegai^der et de restaurer « trace » a chaque appel), 

5 La principale difficulte de cette approche est le calcul statique des valeurs de 
I'empreinte en tout point du programme. Ce calcul reste possible, mais exige 
ou bien une analyse du programme complet (interprocedurale), ou bien 
r etablissement d' invariants sur les valeurs de Tempreinte au debut et a la fin 
de chaque routine. 

10 

Dans r approche par analyse globale, on suppose connaitre, au moment de 
r analyse statique^ le code de toutes les routines pouvant etre appelees 
directement ou indirectement a partir des points d^entree du programme, y 
compris les routines appartenant a d'autres programmes, en particulier celles 
15 de librairies. 



Sous cette hypotheses le procede de detemiination statique de Tempreinte 
decrit ci-dessus s'etend comme suit : au lieu d'analyser et de transformer 
chaque routine individuellement, on les transforme toutes en mSme temps, en 
20 traitant les instructions d'appel de routines (« invoke « call », etc.) comme 
des branchements inconditionnels a la premiere instruction de la routine 
appelee, et les instructions de retour d'appel (« return », etc.) comme des 
branchements vers les instructions suivant immediatement . Tappel 
correspondant. 

25 

En d'autres termes, on travaille non plus sur le graphe de flot de controle de la 
routine, mais sur le graphe de flot de contrSle interprocedural, contenant des 
arcs supplementaires correspondant aux instructions d'appel et de retour de 
routine. On notera que pour les instructions qui determinent dynamiquement la 
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routine a appeier effectivement (comme par exemple I'appel de methode 
virtuelle ou de methode d' interface), on ajoute des arcs de et vers toutes les 
routines en lesquelles I'appel peut se resoudre dynamiquement. Par exemple, 
dans la JVM, une approximation simple de 1' ensemble des methodes cibles de 
5 « invokevirtual Cm », est I'ensemble des methodes «m» dejfinies dans la 
classe « C » ou Tune de ses sous-classes. (On peut obtenir de meilleures 
approximations de cet ensemble a I'aide d' analyses statiques de flot de 
controle.) 

10 Le precede decrit ci-dessus dans le cas d'un routine, applique a ce graphe 
interprocedural, va inserer les ajustements d'empreintes necessaires pour que 
la valeur de I'empreinte soit la meme a tons les sites d'appel d'une m6me 
routine, et a la fin de toutes les routines susceptibles d'etre appelees depuis le 
meme site d'appel. 

15 

Le probleme de I'approche globale ci-dessus est que I'hypoth^se selon 
laquelle on connait le code de toutes les routines est parfois trop forte : on 
connait le code des methodes du package en cours de transformation, mais pas 
forcement celui des routines de iibrairies ou partage avec d'autres 
20 programmes.' 

Une premiere solution est de preserver la valeur de I'empreinte a travers les 
appels k des routines qui ne font pas partie du programme, par exemple en 
sauvant et restaurant la variable « trace » autour de ces appels. 

25 

Une autre solution, qui permet egalement de faire I'economie de I'analyse de 
flot interprocedurale, consiste a etablir le « contrat » suivant entre toutes les 
routines : pour chaque routine de nom «r», si la valeur de I'empreinte est 
« E(r) » a Tentree dans la routine, alors la valeur de I'empreinte est « S(r) » a 
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routine a appeler effectivement (comme par example Tappel de methode 
virtuelle ou de methode. d' interface), on ajoute des arcs de et vers toutes les 
routines en lesquelles Tappel peut se resoudre dynamiquement. Par exemple^ 
dans la WM, une approximation simple de T ensemble des methodes cibles de 
5 « invokevirtual C*m », est T ensemble des methodes « m » definies dans la 
classe « C » ou Tune de ses sous-classes, (On peut obtenir de meilleures 
approximations de cet ensemble a Taide d' analyses statiques de flot de 
controle.) 

10 Le procede decrit ci-dessus dans le cas d'un routine, applique a ce graphe 
interprocedural, va inserer les ajustements d'empreintes necessaires pour que 
la valeur de Teiiipreinte soit la meme a tous les sites d'appel d'une meme 
routine, et a la fin de toutes les routines susceptibles d'etre appelees depuis le 
meme site d'appeL 

15 

Le probleme de Tapproche globale ci-dessus est que Thypothese selon 
laquelle on connait le code de toutes les routines est parfois trop forte : on 
connalt le code des methodes du package en cours de transformation, mais pas 
forcement celui des routines de librairies ou partage avec d'autres 
20 programmes. 

Une premiere solution est de preserver la valeur de Tempreinte a travers les 
appels a des routines qui ne font pas partie du programme, par exemple en 
sauvant et restaurant la variable « trace » autour de ces appels. 

25 

Une autre solution, qui permet egalement de faire Teconomie de Tanalyse de 
flot interproceduxale, consiste a etablir le « contrat » suivant entre toutes les 
routines : pour chaque routine de nom «r», si la valeur de Tempreinte est 
« E(r) » a Fentree dans la routine, alors la valeur de Tempreinte est « S(r) » a 
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la sortie de la routine. Ici, « E » et « S » sent des fonctions associant des 
valeurs d'empreinte arbitraires k des noms de routines, par exemple calculees 
par hachage cryptographique. La signature de la routine (type de ses 
arguments et de ia valeur de retour) peut aussi etre associee au nom, 
notamment si elle permet de distinguer des routines sans rapport entre elles. 

Le « contrat » ci-dessus est simple a assurer : avant chaque instruction d'appel 
a une routine « r », on insere un ajustement de I'empreinte pour I'amener k la 
valeur «E(r)»; et pour chaque instruction de retour d'appel, on insere de 
m6me un ajustement de I'empreinte pour I'amener a la valeur « S(r) ». 



Ce principe s'etend au cas de methodes determinees dynamiquement au 
moment de Fappel. Par exemple, dans le cas de « Java » ou de « Java Cai-d », 
on peut employer des paires « (m, s) » oil « m » est un nom de m^thode et 
« s » une signature de methode. Des hachages de cette paire permettent de 
15 defznir « E(m,s) » et « S(m,s) ». On peut noter que si une methode virtuelle en 
redefinit une autre, ces deux m6thodes ont mgme nom et meme signature, 
done m8mes valeurs « E » et « S ». Le « contrat » sur les empreintes a I'appel 
et au retour de methodes s' applique ainsi de meme maniere. 



Dans la mesure ou seuis sont pris en compte les noms des routines (et 
eventuellement leur signature), la determination des valeurs d'empreinte peut 
s'effectuer routine par routine, sans connaitre Tintegralite du programme. La 
sortie prematuree d'une routine via une exception non rattrapee ne pose pas de 
probleme suppl^mentaire, sous I'hypothese que la machine virtuelle 
(implicitement) ou le gestionnaire d 'exception (explicitement) reinitialise 
toujours I'empreinte k une valeur constante connue lorsqu'une exception est 
declench6e. 
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la sortie de la routine. Ici, « E » et « S » sont des fonctions associant des 
valeurs d'empreinte arbitraires a des noms de routines, par exemple calculees 
par hachage cryptographique. La signature de la routine (type de ses 
arguments et de la valeur de retour) pent aussi etre associee au nom, 
5 notamment si elle permet de distinguer des routines sans rapport entre elles. 

Le « contrat » ci-dessus est simple a assurer : avant chaque instruction d'appel 
a une routine « r »5 on insere un ajustement de Pempreinte pour I'amener a la 
valeur « E(r) » ; et pour chaque instruction de retour d'appel, on insere de 
meme un ajustement de Fempreinte pour Tamener a la valeur « S(r) ». 

10 

Ce principe s'etend au cas de methodes determinees dynamiquement au 
moment de TappeL Par exemple, dans le cas de « Java » ou de « Java Card 
on peut employer des paires « (m, s) » ou « m » est un nom de methode et 
« s » une signature de methode. Des hachages de cette paire permettent de 
15 definir « E(m,s) » et « S(m,s) On peut noter que si une methode virtuelle en 
redefinit une autre, ces deux methodes ont meme nom et meme signature, 
done memes valeurs « E » et « S ». Le « contrat » sur les empreintes a Pappel 
et au retour de methodes s' applique ainsi de meme maniere. 



20 Dans la mesure ou seuls sont pris en compte les noms des routines (et 
eventuellement leur signature), la determination des valeurs d'enipreinte peut 
s'effectuer routine par routine, sans connaitre Tintegralite du programme. La 
sortie prematuree d'une routine via une exception non rattrapee ne pose pas de 
probleme supplementaire, sous Thypothese que la machine virtuelle 

25 (implicitement) ou le gestionnaire d' exception (explicitement) reinitialise 
toujours Tempreinte a une valeur constante connue lorsqu'une exception est 
declenchee. 
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Au lieu de demander au programmeur d'indiquer expHcitement dans le source 
les endroits ou une verification de I'empreinte doit 6tre effectu6e (par exemple 
avec des appels explicites a « checkTraceQ »), ces verifications peuvent aussi 
etre inserees automatiquement par un outil de transformation du code. 

5 

Par exemple, dans le cas de la JCVM, on peut effectuer un controle : 

• avant chaque instruction qui ecrit en memoire persistarite (EEPROM) : 
6criture dans un champ de classe (« putstatic ») ou de d'instance 
(« putfield »), ecriture dans un tableau (« x-astore »), 

10 ® au debut et a la fin de chaque transaction, 

® avant I'appel de certaines methodes de librairie, etc. 



Cela permet notamment de mettre en place une politique de controle 
d'integrite d'execution qui considere que le programme peut executer 
15 n'importe quelles operations, eventuellement perturbees, tant qu'il ne cherche 
pas a modifier la valeur des donnees persistantes et a faire des entrees-sorties. 

La strategic d'insertion automatique des verifications d'empreintes est facile h 
changer, puisqu'elle affecte uniquement la phase de transformation du code. 
20 Elle resulte en pratique d'un compromis a trouver enti-e la frequence des 
verifications et I'augmentation de la taille du code et du temps d'execution dus 
aux operations « checkTrace ». 



Plutot que de modifier explicitement le programme par insertion d' instructions 
25 dans le code (par exemple pour appeler des routines du type « addTrace », 
« checkTrace », « adjustTrace » et « setTrace »), les donnees de prise et de 
controle d'empreinte peuvent atre stockees dans des tables independantes du 
code executable du programme. Ces donnees peuvent comprendre les points 



t 
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Au lieu de demander au prograrameur d'indiquer explicitement dans le source 
les endroits ou une verification de Tempreinte doit 6tre effectuee (par exeraple 
avec des appels explicites a « checkTraceQ »)j ces verifications peuvent aussi 
etre inserees automatiquement par un outil de transformation du code. 

5 

Par exemple, dans le cas de la JCVM, on peut effectuer un controle : 

® avant chaque instruction qui ecrit en memoire persistante (EEPROM) : 
ecriture dans un champ de classe (« putstatic ») ou de d'instance 

(« putfleld »)^ ecriture dans un tableau (« x-astore »), 

10 © au debut et a la fin de chaque transaction^ 

m avant Tappel de certaines methodes de librairie, etc. 

Cela permet notamment de mettre en place une politique de controle 
d'integrite d'execution qui considere que le programme peut executer 
15 n'importe quelles operations, eventuellcment perturbees. tant qu'il ne cherche i;. 
pas a modifier la valeur des domiees persistantes et a faire des entrees-sorties, 

La strategic d' insertion automatique des verifications d'empreintes est facile a 
changer, puisqu'elle affecte uniquement la phase de transformation du code. 
20 EUe resulte en pratique d'un compromis a trouver entre la frequence des 
verifications et T augmentation de la taille du code et du temps d'execution dus 
aux operations « checkTrace ». 

Plutot que de modifier explicitement le programme par insertion d'instructions 

25 dans le code (par exemple pour appeler des routines du type « addTrace », 
« checkTrace »^ « adjustTrace » et « setTrace »), les donnees de prise et de 
controle d'empreinte peuvent Stre stockees dans des tables independantes du 
code executable du programme. Ces donnees peuvent comprendre les points 
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5 



Au lieu de demander au programmeur d'indiquer explicitement dans le 
les endroits ou une verification de I'empreinte doit effectuee (par exempl 
avec des appels explicites k « checkTraceQ »), ces verifications peuvent aussi 
atre inserees automatiquement par un outil de transformation du code. 



source 
e 



Par exemple, dans le cas de la JC VM, on peut effectuer un controle : 
• avant chaque instruction qui ecrit en memoire persistante (EEPROM) : 

ecriture dans un champ de classe (« putstatic ») ou de d'instance 

(« putfield »), ecriture dans un tableau (« x-astore »), 

10 • au debut et ^ la fin de chaque transaction, 

« avant I'appel de certaines methodes de librairie etc. 



15 



20 



25 



Cela permet notamment de mettre en place une politique de contrdle 
d'int^grite d'execution qui considere que le programme peut executer 
n'importe quelles operations, eventuellement perturbees, tant qu'il ne cherche 
pas k modifier la valeur des donnees persistantes et a faire des entrees-sorties. 



La strategic d'insertion automatique des verifications d'empreintes est facile a 
changer, puisqu'elle affecte uniquement la phase de transformation du code. 
Elle resulte en pratique d'un compromis a trouver entre la frequence des 
verifications et I'augmentation de la taiUe du code et du temps d'execution dus 
aux operations « checkTrace ». 



Plutot que de modifier explicitement le programme par insertion d' instructions 
dans le code (par exemple pour appeler des routines du type « addTrace », 
« CheckTrace », « adjustTrace » et « setTrace »), les donnees de prise et de' 
contrSle d'empreinte peuvent etre stockees dans des tables ind6pendantes au 
code executable du programme. Ces donnees peuvent comprendre les points 
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de programme ot une operation d'empreinte est effectuee ainsi que les valeurs 
associees (les arguments de ces operations). C'est la machine d' execution (par 
exemple une machine virtuelle) qui se charge alors d'effectuer ces operations 
lorsque le point de programme courant passe par les points de programme 
5 memorises dans les tables. 



Plutot que I'ai-gument effectif d'une operation d'empreinte, les tables peuvent 
aussi stocker des valeurs qui indiquent quelles donnees dynamiques prendre en 
compte dans reparation. Par exemple, une entree complexe correspondant a 
10 «addTrace» pent indiquer de mettre a jour I'empreinte avec la valeur 
• courante d'une variable ou d'un registre de la machine (pai-ce que sa valeur est 
connu statiquement). 

Un avantage de cette approche est de reduire I'encombrement memoire des 
15 informations de calculs et de controle d'empreinte. En revanche, elle pent 8tre 
couteuse en temps d' execution du fait des parcours de table. En cas de 
problfeme de performance, on pent employer une approche mixte : certaines • 
operations sont calculees automatiquement par la machine d' execution ; 
d'autres operations sont inserees explicitement dans le code du programme ; 
20 d'autres operations encore sont stockees dans des tables. Par exemple, 
r operation « addTrace » pent etre calculee par une machine virtuelle; les 
operations « checkTrace » et « setTrace » peuvent etre exprimees par des 
appels de routine explicites ; et « adjustTrace » pent etre implementee par une 
recherche en table. De plus, pour des raisons d'efficacite, la recherche en table 
25 pour « adjustTrace » pent n'etre effectuee que dans le cas ou un branchement 
est pris (en supposant les ajustements effectifs pratiques uniquement dans ces 
cas-ia). 



10 
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de programme ou une operation d'empreinte est effectuee ainsi que les valeurs 
associees (les arguments de ces operations). C'est la machine d'execution (par 
exemple une machine virtuelle) qui se charge alors d'effectuer ces operations 
lorsque le point de programme courant passe par les points de programme 
5 memorises dans les tables. 



Plutot que I'argument effectif d'une operation d'empreinte, les tables peuvent 
aussi stocker des valeurs qui indiquent quelles donnees dynamiques prendre en 
compte dans I'operation. Par exemple, une entree coraplexe corxespondant a 
« addTrace » peut indiquer de mettre a jour I'empreinte avec la valeur 
courante d'une variable ou d'un registre de la machine (parce que sa valeur est 
connu statiquement). 



15 



20 



25 



Un avantage de cette approche est de reduire I'encombrement memoire des 
informations de calculs et de contrdle d'empreinte. En revanche, elle peut etre 
couteuse en temps d'execution du fait des parcours de table. En cas de 
probleme de performance, on peut employer une approche mixte : certaines 
operations sont calculees automatiquement par ia machine d'execution • 
d'autres operations sont inserees explicitement dans le code du programme ; 
d'autres operations encore sont stockees dans des tables. Par exemple, 
I'operation « addTrace » peut 6tre calculee par une machine virtuelle ; les 
operations « checkTrace » et « setTrace » peuvent etre exprimees par des 
appels de routine explicites ; et « adjustTrace » peut Stre implementee par une 
recherche en table. De plus, pour des raisons d'efficacite, la recherche en table 
pour « adjustTrace » peut n'gtre effectuee que dans le cas ou un branchement 
est pris (en supposant les ajustements effectifs pratiques uniquement dans ces 
cas-ia). 
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Dans la mesure ou les operations de calculs et de controle d'empreinte ne sont 
pas standardisees, un programme instrumente comme decrit ci-dessus pour le 
controle d'integrite d' execution peut ne pas fonctionner sur les plates-formes 
d"" execution qui ne sont pas adaptees, 

5 

Dans le cas ou le code fait explicitement apparaitre des appels de routine 
sur les empreintes (du type « addTrace », « checkTrace », « adjustTrace » et 
«setTrace»)j le programme peut etre accompagne d'une librairie qui 
implemente ces routines, 11 sera alors portable sur toutes les plates-formes 
10 d' execution, Toutefois, si la plate-forme dispose d'une implementation plus 
efficace, elle peut la substituer a celle fournie avec le programme 



Dans le cas d'un codage des prises et controies d' empreintes dans des tables, 
le programme est davantage portable. Par exemple^ dans le cas de d'une 
15 JCVM, les tables peuvent etre foumies sous forme de composants 
persomialises supplementaires : soit la machine les reconnait et les exploite ; 
soit elle ne les reconnait pas et les ignore (et dans ce cas ne pratique pas de 
verification d'integrite d' execution). 
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Dans la mesure ou les operations de calculs et de controle d'empreinte ne sent 
pas standardisees, un programme instrument comme decrit ci-dessus pour le 
controle d'integrite d'execution peut ne pas fonctionner sur les plates-foimes 
d' execution qui ne sont pas adaptees. 



Dans le cas oii le code fait explicitement apparaitre des appels de routine 
sur les empreintes (du type « addTrace », « checkTrace », « adjustTrace » et 
«setTrace»), le programme peut etre accompagne d'une librairie qui 
implemente ces routines. II sera alors portable sur toutes les plates-fonnes 
d'execution. Toutefois, si la plate-forme dispose d'une implementation plus 
efficace, elle peut la substituer a celle foumie avec le programme 



Dans le cas d'un codage des prises et controles d'empreintes dans des tables, 
le programme est davantage portable. Par exemple, dans le cas de d'une 
JCVM, les tables peuvent etre foumies sous forme de composants 
personnalis6s supplementaires : soit la machine les reconnatt et les exploite ; 
soit elle ne les reconnait pas et les ignore (et dans ce cas ne pratique pas de 
verification d'integrite d'execution). 
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Reveudications 

L Procede de contrdle d'integrite d' execution d'un programme par 
verification d'empreintes de traces d'execution, caracterise en ce qu'il 
5 comprend : 

- la mise a jour d'une empreinte representative du chemin d'execution 
et/ou des donnees manipulees lors de P execution du programme^ 

- la comparaison de la valeur courante de T empreinte (calculee 
dynamiquement) a une valeur attendue (fixee statiquement, egale la 

10 valeur que doit avoir T empreinte si T execution du programme n'est 

pas perturbee) en des points determines du programme, 

la realisation d'un traitement particulier effectue par' le programme 
au cas ou T empreinte courante differe de la valeur attendue* 

15 2. Procede seion la revendication 1, caracterise en ce que ladite empreinte ne 
porte que sur les fragments de code critiques du programme. 

3. Procede selon la revendication 1^ cai^acterise en ce que les valeurs 
attendues de T empreinte en des points donnes du programme sont 

20 determinees par une analyse statique de programme qui modifie 
eventuellement le code du programme pour rendre les valeurs d' empreinte 
previsibles. 

4. Procede selon la revendication 3, caracterise en ce que les valeurs 
25 d'empreinte sont determinees par la sequence operatoire suivante : 

- Initialisation de T ensemble des points de progi^amme a explorer au 
singleton constitue de la premiere instruction de la routine. 
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Revendications 



1. Precede de contrdle d'integrite d'execution d'un programme par 
verification d'empreintes de traces d'execution, caracteris^ en ce qu'il 
5 comprend : 

- la mise a jour d'une empreinte representative du chemin d'execution 
et/ou des donnees manipulees lors de I 'execution du programme, 

- la comparaison de la valeur courante de 1' empreinte (calcuMe 
dynamiquement) a une valeur attendue (fixee statiquement, egale la 

1 0 valeur que doit avoir 1' empreinte si I' execution du programme n'est 

pas perturbee) en des points determines du programme, 

- la realisation d'un traitement particulier effectue par le programme 
au cas ou 1' empreinte courante differe de la valeur attendue. 



15 2. Procede selon la revendication 1, caracterise en ce que ladite empreinte ne 
porte que sur les fragments de code critiques du programme. 

3. Procede selon la revendication 1, caracterise en ce que les valeurs 
attendues de I'empreinte en des points donnes du programme sont 
10 determinees par une analyse statique de programme qui modifie 
eventuellement le code du programme pour rendre les valeurs d'empreinte 
previsibles. 



4. Procede selon la revendication 3, caracterise en ce que les valeurs 
25 d'empreinte sont determinees par la sequence operatoire suivante : 

- Initialisation de 1' ensemble des points de programme k explorer au 
singleton constitu6 de la premidre instruction de la routine. 
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Revendications 

1 

1. Precede de controle d'integrite d' execution d'un programme par 
verification d'empreintes de traces d' execution, caracterise en ce qu'il 
5 comprend : 

- la mise a jour d'une empreinte representative du chemin d' execution 

et/ou des donnees manipulees lors de T execution du programme, 

- la comparaison de ladite empreinte (vaieur courante, calculee 
dynamiquement) a une vaieur attendue (tixee statiquement^ egale la 

10 vaieur que doit avoir Tempreinte si Texecution du programme n'est 

pas perturbee) en des points determines du programme, 

- la realisation d'un traitement particulier dans le cas on P empreinte 
courante differe de la vaieur attendue* 

15 2- Procede selon la revendication 1, caracterise en ce que le traitement 
particulier du programme dans le cas oii T empreinte courante differe de la 
vaieur attendue consiste a securiser certaines donnees et/ou a avertir 
Tutilisateur du dysfonctionnement par un signal sonore ou visuel et^ou a 
interrompre, definitivement ou non, T execution dudit programme, 

20 

3. Procede selon la revendication 1, caracterise en ce que ladite empreinte ne 
porte que sur des fragments de code critiques du programme et/ou dans des 
etats du programme juges critiques. 

25 4. Procede selon la revendication 1^ caracterise en ce que ladite empreinte est 
calculee incrementalement le long du chemin d' execution du programme 
par composition successive d'une fonction dont un argument est la vaieur 
courante de T empreinte et un autre argument est une donnee d' observation 
specifique au point et au moment de mise a jour de T empreinte (etat du 
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- Initialisation de I'empreinte courante a la valeur initiale de I'empreinte a 
r entree de la routine. 

- Tant que I'ensemble des points de programme a explorer n'est pas vide : 

* Choix d'un point de programme a explorer (point d'origine). 

* Pour chacun des points de progi-amme resultants possibles apres 
execution de 1' instruction (points cibles) : 

- Si le point cible est un point de forte convergence du flot de 
contrdle et si ce point cible n'a pas encore ete explore, insertion 
d'une affectation de I'empreinte a une valeur quelconque, 
eventuellement donnee. 

- Si le point cible n'est pas un point de forte convergence du flot de 
contrdle et si ce point cible a deja 6t6 explore, insertion apres 
I'insti-uction au point d'origine d'un ajustement d'empreinte qui 
envoie I'empreinte d'origine sur I'empreinte cible. 

- Si le point cible n'est pas un point de convergence fort du flot de 
controle et si ce point cible n'a pas encore ete explore, 

* Insertion au point cible d'une affectation de Fempreinte a la 
valeur d'empreinte resultant d'une execution de I'instruction au 
point d'origine se terminant audit point cible (en fonction de la 
valeur de i'empreinte avant I'instruction), eventuellement 
corrig^e de I'empreinte additionnelie de I'operation d'ajustement 
dans le cas ou elle est aussi un point d'observation de 
r execution, et 

* Ajout dudit point cible dans ledit ensemble des points de 
programme a explorer. 



Precede selon la revendication 1, caracterise en ce que ladite empreinte est 
calculee incrementalement le long du chemin d'ex6cution du programme 



I 
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- Initialisation de Tempreinte courante a la valeur initiale de Tempreinte a 
r entree de la routine. 

- Tant que Fensemble des points de programme a explorer n'est pas vide : 

* Choix d'un point de programme k explorer (point d'origine). 

Pour chacun des points de programme resultants possibles apres 
execution de T instruction (points cibles) : 

- Si le point cible est un point de forte convergence du flot de 
controle et si ce point cible n'a pas encore ete explore, insertion 
d'une affectation de Tempreinte a une valeur quelconque, 

eventuellement donnee. 

- Si le point cible n'est pas un point de forte convergence du flot de 
controle et si ce point cible a deja ete explore, insertion apres 
Finstruction au point d'origine d'un ajustement d^empreinte qui 
envoie Fempreinte d'origine sur Fempreinte cible. 

- Si le point cible n'est pas un point de convergence fort du flot de 
controle et si ce point cible n'a pas encore ete explore. 

Insertion au point cible d'une affectation de Fempreinte a la 
valeur d'empreinte resultant d'une execution de Finstruction au 
point d'origine se terminant audit point cible (en fonction de la 
valeur de Fempreinte avant Finstruction), eventuellement 
corrigee de Fempreinte additionnelle de Foperation d'ajustement 
dans le cas ou elle est aussi un point d' observation de 
F execution, et 

* Ajout dudit point cible dans ledit ensemble des points de 
programme a explorer. 

5. Procede selon la revendication 1, caracterise en ce que ladite empreinte est 
calculee incrementalement le long du chemin d' execution du programme 
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programme et/ou du point d' execution du prograanme et/ou des domi6es 
manipulees). 

5. Procede selon la revendication 4, caracteris^ en ce que ladite fonction est 
parnii Tune des fonctions suivantes : somme de controle (« checksum »), 
congruence lineaire, contrdle de redondance cyclique (CRC), hachage 
cryptographique (« digest »), ou toute autre fonction qui combine les 
operations suivantes : addition, soustraction, « ou » logique exclusif 
(« xor ») avec une constante ou avec ladite donnee d'observation ; rotation 
d'un nombre constant de bits ; multiplication par une constante impaire. 

6. Procede selon la revendication 1, caracterise en ce que I'empreinte est 
ajustee le long des chemins d'execution avant d'atteindre certains points de 
convergence du fiot de controle de maniere a rendre egales les empreintes 
des chemins convergents. 

7. Procede selon la revendication 6, caracterise en ce que 1' operation 
d'ajustement consiste en une combinaison des fonctions suivantes : 
affectation a une valeur constante, addition avec une constante, «ou» 
logique exclusif (« xor ») avec une valeur constante. 

8. Procede selon la revendication 1, caracterise en ce que, en certains points 
du programme, I'empreinte est affectee a une certaine valeur plutot que 
deduite de la valeur d'empreinte precedents 

9. Procede selon la revendication 8, caracterise en ce que lesdits points de 
prograimne sont ceux ou conflue un nombre de branches d' execution 
superieur d un certain seuil et/ou ceux qui sont les points d' entree de 
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programme et/ou du point execution du programme et/ou des donnees 
manipulees). 

5. Procede selon la revendication 4, caracterise en ce que iadite fonction 
consiste en I'une des fonctions suivantes : somme die controie 
(« checksum »), congruence lineaire, controie de redondance cyclique 
(CRC), hachage cryptographique (« digest »), ou combiihiaison des 
operations suivantes : addition, soustraction, « ou » logiqi^e exclusif 
(« xor ») avec une constante ou avec Iadite donnee d'observatidn ; rotation 
d'un nombre constant de bits ; multiplication par une constante i|mpaire. 

6. Procede selon la revendication 1, caracterise en ce que I'enijpreinte est 
ajustee le long des chemins d'execution avant d'atteindre certains points de 
convergence du flot de controie de maniere a rendre egales les empreintes 
des chemins convergents. 

7. Procede selon la revendication 6, caracterise en ce que T operation 
d'ajustement consiste en une combinaison des fonctions suivantes : 
affectation a une valeur constante, addition avec une constante, «ou» 
logique exclusif (« xor ») avec une valeur constante. 

8. Procede selon la revendication 1, caracterise en ce que, en certaiins points 
du programme, I'empreinte est affectee k une certaine valeur plutot que 
deduite de la valeur d'empreinte precedente. 

f 

9. Proc6d6 selon la revendication 8, caracterise en ce que lesdits points de 
programme sont ceux ou conflue un nombre de branches d'execution 
superieur a un certain seuil et/ou ceux qui sont les points d'^ntree de 
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par composition successive d'une fonction binaire dont un premier 
argumait est la valeur courante de I'empreinte et 1' autre argument est une 
donnee d' observation specifique au point de mise a jour de I'empreinte : 
etat du programme et/ou point d'execution du programme et/ou donnees 
manipulees. 

6. Proc6d6 selon la revendication 2, caracterise en ce que ladite fonction 
binaire est parmi I'une des fonctions suivantes : somme de controle 
(checksum), congruence lineaire, contrdle de redondance cyclique (CRC), 
hachage cryptographique (digest), n'importe quelle fonction qui 
combine les operations suivantes : addition, soustraction, ou logique 
exclusif (xor) avec une constante ou avec « x » ; rotation d'un nombre 
constant de bits ; multiplication par une constante impaire. 

7. Precede selon la revendication 1, caracterise en ce que I'empreinte est 
ajustee le long des chemins d'execution avant d'atteindre certains points de 
convergence du flot de contrdle de maniere a rendre egales toutes les 
empreintes des chemins convergents, 

I 

8. Procede selon la revendication 7, caracterise en ce que 1' operation 
d'ajustement est I'une des fonctions suivantes : affectation a une valeur 
constante, addition avec une constante, ou logique exclusif (xor) avec une 
valeur constante. 

9. Procede selon la revendication 1, caracterise en ce que, en certains points 
du programme, I'empreinte est affectee k une valeur (6ventuellement 
donnee) plut6t que deduite de la valem- precedente. 
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par composition successive d'une fonction binaire dont un premier 
argument est la valeur courante de Pempreinte et Tautre argument est une 
donnee d'obsen^ation specifique au point de mise a jour de I'empreinte : 
etat du programme et^ou point d' execution du programme et/ou donnees 
5 manipulees. 

6* Procede selon la revendication 2, caracterise en ce que ladite fonction 
binaire est parmi Tune des fonctions suivantes : somme de controle 
(checksum)^ congruence lineaire, controle de redondance cyclique (CRC), 
10 hachage cryptographique (digest), n'importe quelle fonction qui 
combine les operations suivantes : addition, soustraction, ou logique 
exclusif (xor) avec une constante ou avec « x » ; rotation d'un nombre 
constant de bits ; multiplication par une constante impaire, 

15 7. Procede selon la revendication 1, caracterise en ce que Tempreinte est 

•I 

ajustee le long des chemins d' execution avant d'atteindre certains points de • 
convergence du flot de controle de maniere a rendre egales toutes les 
empreintes des chemins convergents. 

20 8. Procede selon la revendication 7, caracterise en ce que P operation 

d'ajustement est Tune des fonctions suivantes : affectation a une valeur 
constante, addition avec une constante, ou logique exclusif (xor) avec une 
valeur constante. 

25 9. Procede selon la revendication 1, caracterise en ce que, en certains points 

du programme, Tempreinte est affectee a une valeur (eventuelleraent 
donnee) plutot que deduite de la valeur precedente. 
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subroutines et/ou de gestioimaires d'exception, .et en ce que ladite valexir 
affectee est une valeur donnee et/ou une valeur quelconque detemiinee par 
tirage aleatoire et/ou une expression de programme determinee par une 
analyse prealable comme invariante au point de programme considere. 



10. Procede selon la revendication 1, caracterise en ce que la valeur de 
I'empreinte est comparee a la valeur attendue en des points du programme 
determines par leur caracteristique particuliere dans le graphe de flot de 
controle dudit programme el^ou par la nature des operations effectu^es 
auxdits points de programme. 

11. Precede selon la revendication 10, caracterise en ce que lesdits points de 
programme sont situes apres chaque branchement et/ou avant chaque point 
de jointure du flot de controle et/ou avant chaque operation qui ecrit en 
memoire persistante et/ou avant certaines operations cryptographiques 
et/ou avant Tappel de certaines routines de librairie et/ou apres I'appel de 
certaines routines de librairie. 



12.Procede selon I'une des revendications 1 a 1 1, caracterise en ce que la prise 
d'empreinte (calcul et/ou mise k jour et/ou ajustement et/ou affectation) 
et/ou le controle d'empreinte sont realises : 

- explicitement par une instrumentation du code du programme, et/ou 

- explicitement par la machine d' execution (machine virtuelie et/ou 
processeur de la plate-forme d'execution), sur la base 
d'informations compl^mentaires au programme qui indiquent ^ 
ladite machine d'execution en quels points de programme et/ou avec 
quelles valeurs (y compris des vaieurs resultant d'operations 
complexes) effectuer des operations de prise et/ou de controle 
d'empreinte, et/ou 
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1 0 . Precede selon la revendication 9, caracterise en ce que lesdits points du 
programme ou Tempreinte est affectee a une valeur sont les points 
d' entrees des gestionnaires d' exceptions et/ou les points d'enti^ees de 
subroutines. 

5 

1 LProcede selon la revendication 1> cai^acterise en ce que la prise d'empreinte 
(calcul et^ou mise a jour et/ou affectation) est effectuee implicitement par 
la machine d' execution (machine viituelle et/ou processeur de la plate- 
forme d' execution) sur la base d'une observation des instructions 

10 executees. 

12,Procede selon la revendication 11, caracterise en ce que ladite prise 
d'empreinte pent etre dynamiquement suspendue par ladite machine 
d' execution. 

15 

IS.Procede selon la revendication 1^ caracterise en ce que certains calculs, 
mises a jour et controles d'^empreinte sont realises grace a des instructions 
specialisees de la machine d'execution (machine virtuelle et/ou processeur 
de la plate-forme d' execution), 

20 

14. Procede selon la revendication 1, caracterise en ce que le programme est 
instrumente pour inclure des instructions de calcul et/ou mise a jour et/ou 
de controle d'empreinte basees sur la manipulation explicite d'une variable 
representant Tempreinte et/ou Tappel a des routines specialises et/ou 

-I 

25 Temploi d' instructions specialisees de la machine d' execution, 

15. Precede selon la revendication 1, caracterise en ce que le programme est 
accompagne de tables qui indiquent a la machine d'execution des points de 
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1 0. Precede selon la revendication 9, caracterise en ce que lesdits points du 
programme ou I'empreinte est affectee a une valeur sent les points 
d'entrees des gestionnaires d'exceptions et/ou les points d'entrees de 
subroutines. 




1 1 . Precede selon la revendication 1, caracterise en ce que la prise d'empreinte 
(calcui et/ou mise a jour et/ou affectation) est effectuee implicitement par 
la machine d'execution (machine virtuelle et/ou processeur de la plate- 
forme d'execution) sur la base d'une observation des instructions 
1 0 executees. 



15 



20 



12. Precede selon la revendication 11, caracterise en ce que ladite prise 
d'empreinte peut 8tre dynamiquement suspendue par ladite machine 
d'execution. 



13.Proced6 selon la revendication 1, caracterise en ce que certains calculs, 
mises a jour et contrdles d'empreinte sent realises grdce a des instructions 
sp^cialisees de la machine d'execution (machine virtuelle et/ou processeur 
de la plate-forme d'execution). 



U.Procede selon la revendication 1, caracterise en ce que le programme est 
instrumente pour inclure des instructions de calcui et/ou mise a jour et/ou 
de contrdle d'empreinte basees sur la manipulation explicite d'une variable 
representant I'empreinte et/ou i'appel k des routines specialises et/ou 
25 I'emploi d' instructions specialis^es de la machine d' execution. 



15. Precede selon la revendication 1, caracterise en ce que le progiamme est 
accompagn^ de tables qui indiquent a la machine d'execution des points de 
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- implicitement par la machine d' execution (machine virtuelle et/ou 
processeur de la plate-fomie d' execution), sur la base d'une 
observation particuliere des instructions executees. 



5 13.Procede selon la revendication 12, caracterise en ce que ladite 
instrumentation du code du programme est basee sur la manipulation 
explicit© d'une variable ou d'un registre representant Tempreinte et/ou sur 
Fappel a des routines specialisees et/ou sur Temploi d' instructions 

specialisees de la machine d' execution. 

10 

14. Procede selon la revendication 12^ caracterise en ce que lesdites 
informations complementaires sont codecs dans des tables qui associent 
des points de programmes a im code d6finissant T operation a realiser et qui 
ne sont consultees par la machine d' execution que lors de T execution 

15 d' instructions particulieres . 

15, Procede selon la revendication 14, caracterise en ce que lesdites 
instructions particulieres sont des branchements et/ou des ecritures en 
memoire persistante et/ou des appels a certaines routines et/ou certaines 

20 operations cryptographiques. 



16.Procede selon la revendication 1, caracterise en ce que les valeurs 
attendues de Tempreinte et des ajustements d'empreinte en des points 
domies du programme sont determinees par une analyse statique du code 
25 du programme (source ou objet) qui pent simuler le deroulage de certaines 

boucles et recursions et qui pent modifier le code du programme pour 
rendre les valeurs d'empreinte previsibles et/ou pour les controler. 



4 
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programme et des vaJeurs par rapport auxquels I'empreinte doit etre mise a 
jour et/ou contr616e. 



1/ 



16.Proced6 selon I'une des revendications 11, 14 , 15, caracterise en ce que la 
mise a jour d'empreinte est effectuee implicitement par la machine 
d'execution ; le contrdle et raffectation d'empreinte sent effectuees par 
des appels de routines explicites dans le code instrumente du programme ; 
I'ajustement d'empreinte est effectue explicitement par la machine 
d'execution par recherche dans une table, eventueilement uniquement dans 
le cas ot im branchement est pris. 



17. Precede selon la revendication 3, caracterise en ce que : 

le programme est insti-umente manuellement par le programmeur pour 
marquer les points de mise a jour et/ou de controle d'empreinte ; 

les valeurs attendues de I'empreinte en lesdits points de contr61e sont 
determines automatiquement par analyse de programme ; 

le programme est transform6 automatiquement, avant ou apres 
compilation eventuelle, pour mettre en place, pour chacun desdits 
points de controle d'empreinte, un contrdle effectif de I'empreinte pai- 
rapport a la valeur attendue coirespondante. 



IS.Procede selon ia revendication 17, caracterise en ce que, en chaque point 
de contrSle d'empreinte : 

. le marquage du point de controle d'empreinte est realise par I'insertion 
d'un appel a une routine de contrdle d'empreinte prenant en argument 
un entier quelconque ; 

aprds determination des valeurs d'empreinte attendues paz- analyse de 
programme, I'entier qui est un argument de ladite routine de contr61e 



I 
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programme et des valeurs par rapport auxquels Pempreinte doit etre mise a 
jour et/ou controlee. 

16. Procede selon Tune des revendications 11, 14 , 15, caracterise en ce que la 
5 mise a jour d'empreinte est effectuee implicitement par la machine 

d' execution ; le controle et T affectation d'empreinte sont effectuees par 
des appels de routines explicites dans le code instrumente du programme ; 

I'ajustement d'empreinte est effectue explicitenient par la machine 
d'execution par recherche dans une table, eventueilement uniquement dans 
10 le cas ou un branchement est pris. 

17. Proced6 selon la revendication 3, caracterise en ce que : 

le programme est instrumente manuellement par le programmeur pour 
marquer les points de mise a jour et/ou de controle d'empreinte ; 

15 les valeurs attendues de Tempreinte en lesdits points de controle sont 

determines autoraatiquement par analyse de programme ; 

le programme est transforme automatiquement, avant ou apres 
compilation eventuelle, pour mettre en place, pour chacun desdits 
points de controle d'empreinte, un controle effectif de Tempreinte par 
20 rapport a la valeur attendue correspondante. 

IS.Procede selon la revendication 17, caracterise en ce que, en chaque point 
de controle d'empreinte : 

le marquage du point de contrSle d'empreinte est realise par Tinsertion 
25 d'un appel a une routine de controle d'empreinte prenant en argument 

un entier quelconque ; 

apres determination des valeurs d'empreinte attendues par analyse de 
programme, rentier qui est un argument de ladite routine de contr61e 
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17. Precede selon I'une des revendications 4 a 16, caracterise en ce que sont 
foumies a ladite analyse des informations concemant la mise a jour 
d'empreinte (points de programme et natm-e des observations de 
? execution en ce point de programme) et/ou I'ajustement d'empreinte 
(points de programme ou I'empreinte doit etre ajust^ k une certaine 
valeur) et/ou I'affectation d'empreinte (points de programme ou 
I'empreinte doit atre forcee a une valeur) et/ou le controle d'empreinte 
(points de programme ou I'empreinte doit dtre controlee), ces 
informations : 

- 6tant determinees automatiquement conformement au procede selon 
I'une des revendications 6 a 11, et/ou 

- etant donnees sous forme de directives consistant en des instructions 
placees dans le code du programme et operant sur I'empreinte (telles 
que des appels de routine, prenant ou non en argument un entier 
quelconque) et/ou etant foumies sous forme de tables complementaires 
au programme, 

- et pouvant etre completees et/ou modifiees selon les valeurs calculees 
par ladite analyse. 

18. Procede selon la revendication 17, caracterise en ce que, pour chaque 
routine du progranmie, les valeurs d'empreinte attendues sont determinees 
par la sequence operatoire suivante : 

• Initialisation de I'ensemble des points de programme a explorer au 
singleton constitu6 de la premiere instruction de la routine. 

• Memorisation au point d'entree de la routine d'une valeur d'empreinte 
egale a la valeur initiale donnee de I'empreinte. 

« Tant que ledit ensemble des points de programme a explorer n'est pas 
vide : 



1 er depot Modif iee le 08/01/04 

-39- 

d' empreinte est remplace par la valeur d'empreinte attendue 
correspondante. 

19. Precede seion la revendication 1, cai-acterise en ce que le traitement 
5 particulier du programme dans le cas ou T empreinte courante differe de la 
valeur attendue consiste a securiser certaines donnees et/ou a interrompre, 
definitivement ou non, son execution et/ou, quand c'est materiellement 
possible, a avertir I'utilisateur du dysfonctionnement par un signal sonore 
ou visuel. 
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d'empreinte est remplace par la valeur d'empreinte attendue 
correspondante. 



19. Precede selon la revendication 1, caracterise en ce que le traitement 
particulier du programme dans le cas ou I'empreinte courante differe de la 
valeur attendue consiste a securiser certaines donnees et/ou a interrompre, 
defmitivement ou non, son execution et/ou, quand c'est materiellement 
possible, a avertir Tutilisateur du dysfonctionnement par un signal sonore 
ou visuel. 



10 
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- Extraction d'un point de programme (le point d'origine) dudit ensemble 
des points de programme a explorer. 

- Ponr chacun des points de programme resultants possibles apres 
execution de Tinstruction (les points cibles) : 

* Si le point cible comporte une affectation d'empreinte et si ce point 
cible n'a pas encore ete explore, memorisation au point cible de la 
valeur d'empreinte defmie par T affectation. 

Si le point cible ne comporte pas d' affectation d'empreinte et si ce 
point cible a deja ete explore, insertion entre T instruction au point 
d'origine et Tinstruction au point cible d'un ajustement d'empreinte 
qui envoie la valeur de Tempreinte au point d'origine sur la valeur 
de rempreinte raemorisee au point cible. 

* Si le point cible ne comporte pas d'affectation d'empreinte et si ce 
point cible n'a pas encore ete explore, memorisation au point cible 
de la valeur de Tempreinte au point d'origine, modifiee par une 
mise a jour d'empreinte s'il y en a une entre le point d'origine et le 
point cible. 

* Si le point cible n'a pas encore ete explore, ajout dudit point cible 
dans ledit ensemble des points de programme a explorer. 

19.Procede selon Tune des revendications 12 a 18, caracterise en ce que d'une 
part rempreinte porte sur F execution complete du programme (y compris 
avec appels de routines) a partir de ses points d' entree et d' autre part le 
procede selon la revendication 17 est applique a un ensemble de routines 
en txaitant les instructions d'appel statique de routine comme des 
branchements inconditionnels a la premiere instruction de la routine 
appelee, les instructions d'appel dynamique de routine comme des 
branchements conditionnels a la premiere instruction de la routine appelee 
correspondante, et les instructions de retour d'appel comme des 



regue le 27/02/04 



-40- 

branchements vers les instructions suivant immediatement I'appei 
correspondant. 

20. Precede selon la revendication 12, caracterise en ce que le programme 
et/ou la machine d' execution sont instrumentes pour que I'empreinte soit 
sauvegardee a I'appel de certaines routines (telles que celles qui ne font pas 
partie du programme ou qui ne sont pas analysables) et restauree au retour 
de I'appel. 

21. Procede selon la revendication 12, caracterise en ce que le programme 
et/ou la machine d'execution sont instruments pour que I'empreinte soit 
ajustee a I'appel et au retour de certaines routines (y compris dans le cas de 
routines determinees dynamiquement au moment de I'appel) de manidre t 
etre egale : 

- a I'entree de la routine appelee : a une valeur qui depend du nom 
et/ou de la signature de la routine appelee (telle qu'une valeur 
obtenue par hachage cryptographique du nom et/ou de la signature) ; 

- apres retour dans la routine appelante : k une valeur qui depend de la 
meme maniere du nom et/ou de la signature de la routine appelee, 
chaque gestionnaire d'exception concern^ par I'appel de routine 
(c'est-a-dire pouvant etre atteint lors de la levee d'une exception 
dans la routine appelee) devant affecter I'empreinte h une valeur 
d^tenninee. 

22.Procede selon I'une des revendications 3 et 12, caracterise en ce que, dans 
le cas ou I'empreinte est mise a jour implicitement par une machine 
d'execution : 

- la prise d'empreinte pent 6ti'e temporairement suspendue pour eviter 
des calculs inutiles lors de 1' execution de fragments de code non 
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critiques du programme etyou dans des etats du programme juges non 
critiques et/ou lors de 1' execution de certaines routines n'effectuaiit pas 
de controle d'empreinte ; 

la prise d'empreinte, lorsqu'elle n'est pas suspendue, porte sur chaque 
instruction executee, 

* y compris certains de ses arguments immediats et/ou certains des 
invariants du programme pour cette instruction (tels que la hauteur 
de la pile d'operande ou la presence de valeurs de certains types 
dans la pile d'operande) et/ou les choix de branches effectu^s dans 
le cas oil I'instruction est im branchement, 

* mais a la condition que I'insti-uction executee appartienne a une 
classe donnee des instructions a observer, ladite classe etant fixe 
pour la machme d'ex^cution ou Men donnee par une table associant 
a tout code d'instruction un booleen indiquant si I'instruction est a 
observer, et ladite table etant specifique a differentes routines et/ou 
differents programmes. 



23.Proc6d6 selon la revendication 12, caracterise en ce que : 

- certaines operations sur I'empreinte (telies que 1' affectation et le 
controle d'empreinte) sont inserees explicitement dans le code du 
programme ; 

- certaines operations sur I'empreinte (telies que I'ajustement 
d'empreinte) sont effectuees explicitement par la machine 
d'execution en fonction d'informations compl^mentaires au 
programme ; 

- certaines operations sur I'empreinte (telies que la mise a jour 
d'empreinte) sont effectuees implicitement par la machine 
d'ex6cution. 



I 
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24.Proc6de selon la revendication 12, caracterise en ce que : 

- dans le cas ou des operations de prise et/ou de controle d'empreinte 
sont effectuees par des appels de routine, le programme est 
accompagne d'une librairie qui implemente ces routines, ladite 

5 librairie etant pouvant 6tre substituee par une implementation 

particuliere lors du chargement sur une plate-forme d' execution ; 

- dans le cas oti les operations de prise et de controle d'empreinte sont 
exprimees par des informations complementaires au programme et 
ou la plate-forme d' execution ne salt pas et/ou ne peut pas et/ou ne 

10 veut pas exploiter ces informations, lesdites informations sont 

ignorees pour permettre 1' execution sans le contrdle d'integrite. 



25. Precede selon I'une des revendications 12 et20, caract6rise en ce que la 
machine d' execution du programme dispose d' instructions specialisees 

15 pour le calcul d'empreinte et/ou la mise a jour d'empreinte et/ou 
I'ajustement d'empreinte et/ou I'affectation d'empreinte et/ou le controle 
d'empreinte et/ou la sauvegarde d'empreinte k I'appel d'une routine et la 
restauration d'empreinte au retour d'une routine, ces instructions 
apparaissant explicitement dans le code du programme et/ou etant utilisees 

20 pour mettre en oeuvre la machine d' execution. 



26.Systeme d' execution permettaiit le controle d'integrite d' execution, 
caract6rise en ce que iedit systeme uiclut im raicroprocesseur qui dispose 
d' instructions specialisees pour le calcul d'empreinte et/ou la mise a jour 
25 d'empreinte et/ou I'ajustement d'empreinte et/ou I'affectation d'empreinte 
et/ou le controle d'empreinte et/ou la sauvegarde d'empremte a I'appel 
d'ime routine et la restauration d'empreinte au retour d'une routine, 
conformement au precede selon I'une des revendications 1 a 25. 
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